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]

Reply via email to