Hi Rishi, See my comments below. George ________________________________
From: Rishi krish [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 8:46 PM To: [email protected] Cc: [EMAIL PROTECTED] Subject: Re: single sign on with axis2 Hi George thanks for ur reply. Lets for simplicity sake take the simple password based LDAP authentication [I know most of our customers use this - but some use x509 certificates]. I have googled and kind of come to this conclusion that for Web service SSO - SAML is the best solution. But my problem is my knowldege on SAML is almost 0 and axis2 does not have good examples illustrating how to use SAML with axis2. I am pasting a comment by Anne Thomas Manes sometime back in this grp abt SAML ------------------------------------Annes comments in this news grp------------------------- SAML provides a standard XML format to express and exchange security assertions. Assertions come in three flavors: authentication, authorization, and attributes. You get these assertions from some type of trust authority, such as a single sign-on service or an entitlement service. SAML defines the protocols (SOAP messages) that you use to get these assertions. One of the primary reasons why you might want to use SAML is to support single sign-on. But if you don't have a SAML authentication authority, then you probably don't want to use SAML. In WS-Security speak, a SAML assertion is an XML security token. Once you have a SAML token, you can relay that security information in your SOAP messages (in a SOAP header) using WS-Security. WS-Security also supports a number of other security tokens, such as X.509 certificates, Kerberos tickets, XrML tokens, XCBF tokens, or a simple userID/password token. I think WSS is the best approach today to implement single sign-on within a single trust domain. If that trust domain is implemented using Active Directory, then I suggest using Kerberos tickets for your authentication token. For any other type of trust domain, use SAML and a SAML-compliant single sign-on service. Add Liberty to the mix to support single sign-on across trust domains. SAML-compliant single sign-on products are available from Sun, Entrust, Securant, Entegrity, and Netegrity. I'm sure there are others. ---------------------------------------------end Anne's comments--------------------------------------------- So what I get from these comments are 1>u need a "SAML compliant single sign on service" - Q1> is this the LDAP server or this is some other service? [GS] No , LDAP is your Identity Provider. Such service would be a STS (Security Token Server in WS-Trust talk). Google around for "WS Trust" and "STS". Axis2 will ship a STS service called Rahas (which BTW I am anxiously awaiting) but its not part of the standard Axis2 1.1 distro. Q2>Is this entity the same as the "SAML authentication authority"? I don't know what you mean by this. The STS issues security tokens (SAML, UsernameToken, Kerberos tickets, whatever you ask and/or it can issue) which you (the user) then attach to the SOAP message before you call a service provider. The service provider validates that this token comes from a trusted source and message integrity, by checking its signature and who signed it and trusts the digital subject described by this token. 2>SAML defines protocols to talk to a "SAML compliant single sign on service" to get back assertions Q>can I assume that the Axis client [ServiceClient] communicates with the "SAML compliant single sign on service" to get back the asertions and then add them to the WS Security header of the out going SOAP message? Yes, by using WS-Trust exchange pattern. WS-Trust is built on top of WS-Security. 3>Can I assume that to talk to the "SAML compliant single sign on service" - the axis ServiceClient has to be configured via the saml.properties and the SAMLTokenSigned/Unsigned action? How does the ServiceClient know abt logged in the user identity [probably here is where the dynamic runtime user id setting is going to come as compared to the static axis2.xml security user configuration]? In WS-Trust it is the service client responsibility to obtain security token before calling the service provider. It does this by contacting the STS with an Issue request, type of token requested and some other claims about the subject (for example UsernameToken that identifies the subject). For the second part of your question, I am a little fuzzy too, may be Ruchith can help - once you obtain a SAML token, do you manually stuff it in the message header in wsse envelope or there is some configuration method? 4>Where can I get a documentation of how I can configure a Axis Web Service client for putting a SAML SSO token in the WS Security header? Is the client configuration [samp.properties] pretty standard for all "SAML compliant single sign on service" ? I have found the integration tests in the subversion repository to be great source of how things are done. I've learned alot from them and by looking at the rahas source. Is there any article [ws02??] for axis2 client/service setup for SAML where I can refer and get a hold on how to use/configure SAML+Axis2 or if anyone in this grp has successfully used SAML with Axis2 and can share some sample configurations [client and server] - it would be of great help to me. I dont know but may be others know? Google around for "WS-Trust", "WS-Federation Active Requestor Profile", "STS", "IdP", "Identity Provider". This should get you started on theory. However be aware that what the standards call for could be a little bit on the heavy side for your particular example. If you want to cut corners, you can just issue a self-signed SAML token from Service A which you sign with ServiceA's certificate and have ServiceB trust tokens signed by ServiceA. This can definetly can be done by rampart with configuration only or minimal effort. thanks Rishi On 11/16/06, George Stanchev <[EMAIL PROTECTED]> wrote: Hi Rishi, How is your user authenticating against the LDAP? Simple password based authentication or some kind of certificate based authentication? You will need to establish trust between your Server A and Server B somehow. You can use an X509 certificate or simple public/private key pair which you need to exchange. Once Server B knows and trusts Server A, then you can issue your ServerA->ServerB request with either UsernameToken or SAMLTokenSigned action. In the first case you can sign the message or portion of your message including the token with ServerA's certificate that was used to establish the trust. In second case, you can just sign the SAML token with that certificate (or public key). The ServerB then would have to check if the certificate is trusted and trust the Principle relayed via the token. As far as what token type to use - depends what Principle claims you have to supply. UsernameToken is good about relying usernames but thats about it. With SAML you can add additional claims in the token. Both those scenarios are supported by Axis2/rampart, however you still have to do the handling on your ServerB to determine if the incoming message was issued by trusted authority. Axis2/rampart allows dynamic configurations - look at the user's manual to see how you can do it. George ________________________________ From: Rishi krish [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 2:53 PM To: [email protected] Subject: single sign on with axis2 Hi I am new to axis2 and am trying to figure out whats the best approach for this scenario: The user logs in to a j2ee application running in a j2ee server [say Weblogic/Websphere]. The user is validated using a LDAP server [the j2ee server handles that part] and after the authentication we have a user Principal. Now the user need to invoke a Web service hosted by another server [j2ee or .net] which uses the same LDAP repository for authentication. I am developing the web service client using the ServiceClient class in axis2 and the code is sitting in the first server. I am at loss as to what kind of security token should I use to communicate with the Web service. I have to pass the Principal information to the other side and not sure whether to use the UserNameToken. The problem here is I dont beleive the Principal has any info abt the password and that makes me beleive that I cannot use UserNameToken. OR should I use SAML token and if thats the case I have no idea where to get info to set up a SAML token using the ServiceClient api. OR Axis2 ServiceClient api does not support this scenario. Also along side I had another question - All the samples for UserNameToken shows the userid preconfigured in the clients axis2.xml. Can the userid be fed to the ServiceClient api programmatically. What I am trying to acheive is dynamic userid [which might change per invocation] and not a static preconfigured one. Though this will not help me in the above singlesign on scenario OR may be it will - pls suggest. -- thanks Rishi ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -- thanks Rishi ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
