 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / July 2005SecurityContextTokens and SecureConversation
Hi, I need to implement my own issuing of SCTs through a negotiation between client and server resulting in client and server agreeing on a common symmetric key. The original request will be unsigned - the trust is established through the negotiation. Is it possible to extend WSE 2.0 to allow for this ? Or is the whole secureconversation part of WSE completely tied to certificates ? Thanks, Here is one I did using public key (signed assem) on client and private rsa key on server: http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry  SignatureWilliam Stacey [MVP] > Hi, > [quoted text clipped - 10 lines] > > Thanks, Thanks for your reply. The exchange in your example uses proprietary elements (the SCTMsg). I would like to comply with the WS-Trust specs, i.e. use RequestSecurityToken / RequestSecurityTokenResponses for the negotiation as specified in the Negotiation and challenge extensions of the WS-Trust specification. The spec allows for custom tags to be inserted in the RequestSecurityToken element. Of course, it is possible to do this by rewriting the SCTMsg class to something that in XML representation is a RequestSecurityToken element, but I was wondering if it is possible to extend the WSE SecurityContextTokenService and SecurityContextTokenServiceClient classes instead ? What I need to do is to insert my own custom tags in the RequestSecurityToken that is sent from the extended SecurityContextTokenServiceClient class. Likewise I will have to implement support for recieving RequestSecurityTokenResponse in the extended SecurityContextTokenService class (as the protocol i'm implementing is a 4-way exchange). Do you have any clues whether this is possible, or should I simply implement it from scratch (SoapClient/SoapService) like your example ? > Here is one I did using public key (signed assem) on client and private rsa > key on server: [quoted text clipped - 14 lines] > > > > Thanks, I am now confused. It seemed you had asked to get a SCT without using certs. Do do that, you need to do it yourself as WS SCTs can be had with http and certs only (IIRC). If you want to go outside that (i.e. TCP and/or no certs), then you need to do something like this. Note, once you have the SCT, the rest of the conversation is standard WS-* stuff using the SCT. SignatureWilliam Stacey [MVP] > Thanks for your reply. > [quoted text clipped - 45 lines] >> > >> > Thanks, Please apologize the confusion - but I'm new to WSE ;-) My concern is the actual soap messages exchange when aquiring the context token. I want to use the WS-Trust Negotiation model to establish the secure context something like this : C -> S : RST S -> C : RSTR C -> S : RSTR S -> C : RSTR The last RSTS from the server will contain an identifier used by both client and server. The common symmetric key will be derived by both the client and server from my protocol specific elements embedded in the RST/RSTRs. This kind of exchange is fully in line with the WS-SecureConversation and WS-Trust specs. Establishing a secure context is in no way bound to http or certs from the specs - this must be a WSE issue. > I am now confused. It seemed you had asked to get a SCT without using > certs. Do do that, you need to do it yourself as WS SCTs can be had with [quoted text clipped - 51 lines] > >> > > >> > Thanks, > The last RSTS from the server will contain an identifier used by both > client > and server. The common symmetric key will be derived by both the client > and > server from my protocol specific elements embedded in the RST/RSTRs. This is basically what mine does in one request/reply pair. If you want exactly what RSTS does, then why not use that? If you want to change something, you can build on mine or rebuild your own. What are you doing again and why can't you use what is in WSE already? SignatureWilliam Stacey [MVP] > This kind of exchange is fully in line with the WS-SecureConversation and > WS-Trust specs. Establishing a secure context is in no way bound to http [quoted text clipped - 63 lines] >> >> > >> >> > Thanks, I'm trying to establish trust - in the form of a context token - using a password based authentication and key exchange protocol. The WS-SecureConversation spec recommends that this is done by exchanging RST and RSTR messages. In my case the initial RST will by unsigned. There is no initial trust - the trust is established through the negotiation. Please note, that my goal is to exchange these WS-* compliant messages - not specifically to use WSE, or for that matter .Net. I am doing this as a part of a project on password based protocols to demonstrate partical use within existing specifications. The issue I have with your example is that it does not use the recommeded RST/RSTR XML in the exchange, but instead exchanges some proprietary XML (the serialized SCTMsg). I would have liked the information in the SCTMsg to have been embedded in RST/RSTR messages. I have tried to do this by extending the SecurityTokenService and SecurityTokenServiceClient class, but as far as I can see the SecurityTokenService class only supports signed requests ? Is that correct understood ? A bit strange, since the clientside SecurityTokenServiceClient supports unsigned requests ? -Peter > > The last RSTS from the server will contain an identifier used by both > > client [quoted text clipped - 75 lines] > >> >> > > >> >> > Thanks, > The issue I have with your example is that it does not use the recommeded > RST/RSTR XML in the exchange, but instead exchanges some proprietary XML > (the > serialized SCTMsg). I would have liked the information in the SCTMsg to > have > been embedded in RST/RSTR messages. Just change the SCTMsg to be same names and format of RST/RSTR then. I don't have the need to rework the sample myself, but you should be able to it with some work. > I have tried to do this by extending the SecurityTokenService and > SecurityTokenServiceClient class, but as far as I can see the > SecurityTokenService class only supports signed requests ? Is that correct > understood ? > A bit strange, since the clientside SecurityTokenServiceClient supports > unsigned requests ? If the requestor doesn't have a X.509 then you need some form of TLS connection or prior ephemeral key. IMO, at some point you will need some form of PKI to bootstrap the process. Wish you luck. SignatureWilliam Stacey [MVP]
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.