Thank you very much Ruchith! I was successful in running your code! I think this could be a nice beginning point. Do you think in this way i can add in RequestSecuritTokenResponse exchanged by client and custom token issuer, any xml structure i need as child of RequestSecurityTokenResponse and then extract the information i need for the negotiation to generate the appropriate response? Thanks again. Regards, Filippo A.
2012/2/10 Ruchith Fernando <ruchith.ferna...@gmail.com> > Hi Filippo, > > Here's how I got the STS to issue a custom token without securing the > messages. > > - Created a custom issuer (org.custom.MyIssuer.java attached) > Compiled this class, created a jar and included it in the classpath > of the axis2 server. > I used the simple server that ships with axis2, hence placed this > jar in the axis2 lib dir. > > - Created an STS configuration (services.xml) which uses the above > issuer. Created a service archive with this file (sts.aar in which the > META-INF directory contains this services.xml) and included it in > axis2 services. This services.xml file defines one operation : > IssueToken which is does not enforce any security. If you run into a > case where you need to call IssueToken operation with security policy > enforced then you may add another operation to the sts and engage > rampart on that operation (Note that you will need to have a distinct > action URI associated with that operation). > > - Updated rampart-trust jar to skip rampart requirement to skip the > security header requirement (attached is the updated jar) and replaced > the rampart-trust jar in axis2 lib. > > - Coded a custom client to talk to the service > (org.custom.SimpleClient.java attached). > > Hope this helps! > > Thanks, > Ruchith > > On Thu, Feb 9, 2012 at 5:20 PM, Ruchith Fernando > <ruchith.ferna...@gmail.com> wrote: > > 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 > > > > -- > http://ruchith.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > For additional commands, e-mail: java-user-h...@axis.apache.org >
