Hi Filippo, IMO not many people use this kind of a communication pattern to establish a security context. To my experience I haven't seen this is implemented in other popular frameworks also (I maybe wrong). I think for the same reason interoperability is also not clearly defined for this kind of communication. But its great to have a such implementation. I have some feedback on your suggestions when compared with current Rampart implementation. (Please see inline comments)
On Wed, Feb 8, 2012 at 10:40 PM, FILIPPO AGAZZI <filippo.aga...@studenti.unipr.it> wrote: > Hi George and Prabath, > thank you very much for your answers. I've read about CXF STS and OpenSSO, > but until now i haven't found anything about supporting WS-Trust negotiation > and challenge framework, although i'm not absolutely sure about this. > > Prabath, thanks, now i try to explain what i'm trying to do. As I said, i > need a service that, when a client attempts to access, asks the client some > type of authorization, and this is released through a negotiation process > between client and service. This authorization can be obtained by the > client, with the presentation of some credentials (service has, for example, > a policy that requires the client possessing two credentials to have > access). Also the client has some policy protecting his credentials, and ask > the service to send it credentials in its turn, that the client asks in > order to disclose the credentials asked by the service. This is the > negotiation process i need, and i want to do this using WS-* standard: this > is the reason why i thought about WS-trust negotation extension, that > describe how client and service (probably the STS linked to the service) can > exchange multiple (how much are needed) RequestSecurityTokenReponse > messages,after the first RequestSecurityToken sent by the client. > > So i want to build a scenario where client and STS can exchange many > RequestSecurityTokenResponse messages, where an important thing is that > client and STS are completely unknown, and client hasn't got the STS policy. > And here, the first question: in my experiments i figure out that STS needs > some authentication and Cryptography in messages exchanged with the client > (i refer to sample05 in Rampart distribution), and sts need to have > client.jks: this doesn't match with my requirements, is it possible have an > STS without any security policy mandatory for the messages (such as crypto > or signature)? Practically we need some mechanism to authenticate users against the STS. Therefore we must have a security policy to authenticate users against the STS. I just test whether it is possible to invoke STS without a policy, but it seems it is not possible as per current implementation. I mean that STS release a security token to the client, that > it uses to call the service, but the STS-policy, protecting the realising of > the security token, is sent during the negotation. > > Then, now i add more details: the message exchange pattern i need is: > client send a RequestSecurityToken message to the STS (and he doesn't know > nothing about STS, so client doesn't add any security header in the > message). STS answers with a RequestSecurityTokenReponse: this message have, > as child of <wst:RequestSecurityTokenResponse>, xml custom elements, > definded by a schema. These xml elements are structures that can contain > some other custom xml child element (representing, for ex, negotation > information, as negotiation strategies supported etc..), and also > <wsp:policy> element (policy that STS asks for relasing security token for > the linked service). Client, in your turn, answers with another > RequestSecurityTokenResponse, containing its negotiation information and its > policy, within xml custom elements, contained by > <wst:RequestSecurityTokenResponse>. > After this 2 initials RequestSecurityTokenReponse messages, negotiation > starts with some exchange of other RequestSecurityTokenReponse, that contain > credentials both of the client and of the STS of the service the client > wants to access. In this way i can have a negotiation process within > WS-trust standard. > > I don't know if i could explain it in a good way, but summarizing i need > client and STS custome exchanges of RequestSecurityTokenResponse containing > arbitrary XML structures. I see in ws-trust 1.4, the <CustomExchange> > element, that i thought can be used to contain my custom element. I need > also that client and STS (or service) communicate each other with their own > trust negotiation framework, before answering to the other part. > As a solution, i thought to implemente a client-handler and a STS-handler, > in order to have as many messages as i want between client and STS, and in > the hanlders building my soap custom message..but i have no idea how to make > the handlers communicating each other, without let the messages hitting > client and STS..i mean that these handlers need to be the first who handle > the incominig messages, in order to have the scenario i described.Do u think > is it a possibile solution? Above could be a possible solution. But let me briefly describe how existing Rampart handles, this. In the current Rampart engine we have a specific client called “STSClient” [2]. STSClient is responsible for creating “RequestSecurityToken” with appropriate data. “STSClient” also sets an special action (http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT). If there is a security policy attached to STS client it will process approprate security and send. Once server side receives the message it will first process the security headers coming with “RequestSecurityToken”. (I guess in your case you have to modify this code to work without security headers for “ RequestSecurityToken”). Once security headers are processed, message will be routed to “STSMessageReceiver” [1] (Rampart identifies that message should be routed to STSMessageReceiver by looking at the action). “STSMessageReceiver” is responsible for processing “ RequestSecurityToken” and creating “RequestSecurityTokenResponse”. As per now we have a single round. But in your case you need to have several rounds of message exchanges before you negotiate a secret (establing a context). In summary, within Rampart we are handling communication with STS using a client and a message receiver. As per my understanding you should also be able to extend the current “ STSMessageReceiver” implementation and implement your logic. [1] http://svn.apache.org/repos/asf/axis/axis2/java/rampart/tags/v1.6.1/modules/rampart-trust/src/main/java/org/apache/rahas/STSMessageReceiver.java [2] http://svn.apache.org/repos/asf/axis/axis2/java/rampart/tags/v1.6.1/modules/rampart-trust/src/main/java/org/apache/rahas/client/STSClient.java Hope this information is useful. Thanks AmilaJ > > Any idea, suggestions is very very appreciated! Sorry for the lenght of this > message!!! > Thank a lot in advance, > > Best regards > > Filippo Agazzi > > > 2012/2/8 Prabath Siriwardena <prab...@wso2.com> >> >> Hi George, >> >> Sure.. you are somewhat out dated :-) >> >> The rampart STS has support for WS-Trust 1.3 as well as some parts of the >> WS-Trust 1.4 and we ship this with WSO2 Identity Server product - and the >> STS been used in real production scenarios.. >> >> Hi Flippo, >> >> Yes, as you mentioned your requirement is not supported yet.. But we can >> help you building it.. Please provide further insights in to the >> requirement... >> >> Thanks & regards, >> -Prabath >> >> On Wed, Feb 8, 2012 at 8:29 AM, George Stanchev <gstanc...@serena.com> >> wrote: >>> >>> Hi Filippo, >>> >>> >>> >>> I don’t believe the Axis2 STS is mature enough to support what you are >>> asking about. Neither rampart contains a general-purpose WS-Trust client. >>> AFAIK the main purpose of the Axis2 STS is to server SCTs for >>> WS-SecureConversation. Granted, I’ve stopped following its development for a >>> while so others might correct me if I am wrong. >>> >>> >>> >>> I am not sure anything you ask for is available as open source. You can >>> try checking out the Apache CFX STS implementation which was donated by >>> Talend which could be more mature. CXF also might have a more mature client. >>> Other than that, you can also check Sun’s OpenSSO or any other more >>> comprehensive SSO implementation. [1] contains some starting point links. >>> >>> >>> >>> George >>> >>> >>> >>> >>> >>> [1] http://kantarainitiative.org/wordpress/programs/iop-saml/ >>> >>> >>> >>> From: FILIPPO AGAZZI [mailto:filippo.aga...@studenti.unipr.it] >>> Sent: Tuesday, February 07, 2012 7:28 AM >>> To: java-user@axis.apache.org >>> Subject: [Axis2] [Rampart] ws-trust negotiation and challenge extension >>> support >>> >>> >>> >>> Hi all, >>> i'm Filippo Agazzi, an Informatic Engineer student at University of >>> Parma, Italy. i'm working on a thesis about "Automated trust negotiation >>> using ws-* standard", and i need, as a basis, to have a client and a service >>> (probably a STS), challenging each other and exchanging multiple >>> RequestSecurityTokenReponse message, before a final message is sent by the >>> service to the client. I see that ws-Trust includes a negotation and >>> challenge framework; so my question is: is there any support or >>> implementation in axis2 and rampart (rahas) for this ws-trust extension? >>> I've already studied and successfully run the samples in rampart >>> distribution, for example "sample05", where client asks for a saml token to >>> a STS; but that is a single round trip, instead i need more rounds and i >>> need to insert xml custom element (for example wsp:Policy element) in >>> RequestSecurityToken and RequestSecurityTokenReponse messages. Here the link >>> to the standard section i refer to : >>> http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html#_Toc212615468. >>> >>> Eventhough there isn't any support/implementation in Axis2 for ws-trust >>> negotation and challeng extension, someone have any ideas on how this can be >>> done? Anyone, plese, can indicate me a way on how implement this? I've >>> searched a lot and widely on the web, but i can't find nothing really >>> useful, so i'm hard blocked on this point. >>> >>> Thank you very much in advance. >>> >>> Best regards. >>> >>> Filippo Agazzi >>> >>> >> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> > -- Mobile : +94773330538 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional commands, e-mail: java-user-h...@axis.apache.org
