Hi Michael, In addition to be a structure for carrying identity information, SAML defines different profiles, bindings, etc protocol related specifications for requesting, canceling, verification, etc manipulations of security tokens. In a sense it does the same thing as WS-Trust but for SAML-tokens while WS-Trust allows other tokens as well. The internet2 Shibboleth project uses fully SAML-based identity solution - you might want to check it out (google it, it will come up).
Its not only the token, but how you request it, cancel it in secure manner etc. In addition, if you are building a web based single sign on solution, you migh want to check the WS-Federation Passive Requestor profile, which defines a standardized way of building web-based SSO solutions which can be federated. Best Regards, George -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 9:10 AM To: [email protected] Subject: RE: Axis2 and SAML Thanks George, For some reason it took me a whole week to come across this post. Anyway, you say you'd recommend SAML, but you also say you prefer WS-Trust. I'm a bit confused - I thought SAML was a language for representing users and their permissions, whereas WS-Trust was for exchanging security tokens. In other words, I thought these addressed two different classes of use cases. I'm still very new to this stuff... cheers, md > -----Original Message----- > From: George Stanchev [mailto:[EMAIL PROTECTED] > Sent: Monday, June 18, 2007 12:15 PM > To: [email protected] > Subject: RE: Axis2 and SAML > > > Hi Michael, > > The support for SAML in Rampart is rather weak and if you go with > SAML, do not expect much help from it. It uses is internally for the > more of a special case of WS-SecureConversation SC token. > In addition, in Rampart 1.1 there was a way to create a signed and > unsigned SAML tokens but you get the token only in the outbound SOAP > and you don't have much control over what goes inside (for example > SAML attributes). > > I'd definetely recommend SAML as the way to go for tokens in an SSO > implementation - it is standard, its been around for a while, its > proven, it is signed and it is extensible. In addtion, the SAML 2.0 by > it self defines a security "language" rivaling WS-Trust so you can > just stay with it, though I prefer WS-Trust based exchanges as more > standard and supported way to go. > > Internet2's OpenSAML libraries are the only mature open source SAML > libraries that I know of. > Version 1.1 supports SAML 1.0 and 1.1 and version 2 supports all SAML > standards. OpenSAML2 is still being developed and even though it is > stable for most parts it will change somewhat around some of the more > peripherical cases (Encryption is one that comes to mind). Though it > does have a steeper learning curve, I'd start with OpenSAML2. > > Good luck with the SSO implementation. > > Best Regards, > George > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, June 15, 2007 2:36 PM > To: [email protected] > Subject: Axis2 and SAML > > Hi, > > I'm working on a single-sign-on service for our organization's > intranet. > The idea an application can send a username, and password and > application identifier to the service, and the service responds with a > list of permissions that the user has for the particular application. > > Just to get started, I created a service that returns a string from > which I can parse out what I need. But I'm wondering if I could gain > anything (such as greater interoperability) by using a standard such > as SAML to represent a user and his/her permissions. > > I see that there is a framework for working with SAML: > http://www.opensaml.org/ > > Does this sound reasonable or am I heading in the wrong direction? > Will I end up with a schema nightmare if I return a SAML xml document > as a service payload? BTW, I plan on writing the client and server by > hand, because later I will probably want to add rampart and have more > control over headers and stuff. > > Thanks > Michael Davis > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ********************************************************************** > 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. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
