Hi Filippo, On Thu, Feb 9, 2012 at 3:51 PM, Ruchith Fernando <ruchith.ferna...@gmail.com> wrote: > On Thu, Feb 9, 2012 at 7:03 AM, FILIPPO AGAZZI > <filippo.aga...@studenti.unipr.it> wrote: >> Hi Amila, >> thanks for your response. So you suggest to use >> http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT, instead of >> http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue ? I've already think >> about this, but i don't understand what are the advantages that i get using >> SCT action, rather than Issue action, if you could explain me, i really >> appreciate. > > Using http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT would route > your request to the security context token issuer that is included in > the rampart STS implementation. I believe you will have to use > "http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue"; and use a > custom token type. > > This leads to coding your own token issuer which should maintain some > state with respect to the stage in the negotiation the issuer is in > with respect to a particular client. > >> >> >> 2012/2/9 Amila Jayasekara <ami...@wso2.com> >> >>> >>> 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”). >> >> >> This is a useful suggestion, but i'm not sure of which part of code i have >> to modfy. Do you mean i have to modify rampart handler, to make it work >> without security header? If i can do this, it could be a good way. And then, >> modifying STSMessageReceiver, i could be able to establish an exchange of >> RequestSecurityTokenReponse between STSClient and STSMessageReceiver, are >> you suggesting this way? Another doubt: with this scenario, i don't have to >> implement any Issuer? > > What if you don't engage rampart when engaging rahas to setup the STS? > In that case it won't require the presence of a security header. If > this is the case it should simply let the RST through to the > STSMessageReceiver where it will look at the request type and token > type to pick the appropriate issuer (a custom issuer in this case). > This way you will only have to write your own issuer. I'll verify > whether this is possible if I can find some time. >
I just hacked up a small STS to test my claim of invoking the STS without engaging ranpart(i.e. without the requirement of a security header) . Rahas currently requires the presence of security headers (org.apache.rahas.RahasData#processWSS4JSecurityResults()). I made this requirement optional in my code and then I was able to successfully deploy a custom token issuer. I was able to communicate with this token issuer using a custom client without using STSClient. I will post a link to the code. Thanks, Ruchith --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional commands, e-mail: java-user-h...@axis.apache.org
