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. Anne > -----Original Message----- > From: Naresh Bhatia [mailto:[EMAIL PROTECTED] > Sent: Monday, March 17, 2003 10:26 AM > To: [EMAIL PROTECTED] > Subject: RE: Authorization using WS security and SAML > > > Hi Anne, > > You touch on some interesting points. I agree that one can implement > authentication or authorization purely using transport level security > mechanisms and JAAS. However what is the best approach today to > implement single-sign on. In my application, the end user sends SOAP > messages to my web service along with some credentials (in the SOAP > header). In turn, I need to call bunch of other Web Services on behalf > of the user. These web services also expect to authenticate the original > user. Fortunately the design of these "other" web services is also in my > control. So what is the best approach in such situations? It seems that > solutions such as Kerberos and SAML are all competing against each > other. Could you explain the various layers involved in coming up with a > single-signon solution and some pointers to making tecnology decisions? > > Thanks. > Naresh > > -----Original Message----- > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > Sent: Monday, March 17, 2003 9:00 AM > To: [EMAIL PROTECTED] > Subject: RE: Authorization using WS security and SAML > > > 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. > > But you don't need to use either SAML or WS-Security to implement > authentication or authorization. There are a number of authentication > mechanisms that you can use: HTTP Basic, HTTP Digest, SPKM (X.509 > certificates). The challenge that you need to solve is mapping these > transport-level authentication mechanisms to a security principal within > your environment. You will need to implement a transport-level > interceptor to capture the authentication information and map it to a > principal. Then you need to carry that context with your request until > you get to the service dispatch point, at which point you can use JAAS > to determine if that principal is authorized to access the requested > service. > > If you're using WS-Security, then you must write a header processor that > takes the security token and maps it to a principal, and then use JAAS > to check authorization. > > Anne > > > -----Original Message----- > > From: Nisha Menon [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 17, 2003 5:25 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Authorization using WS security and SAML > > > > > > > > Yip... I get it now... :-) > > > > Ok so here's the deal... > > > > The SOAP message that comes in is parsed and the authentication > > information is extracted. (I guess that module would need to look out > > for a pattern followed since we'd have to know which standard is being > > > used to pass the authentication information. i.e username/password or > > certificates or security tokens etc) Depending on that, we'd have to > > re-route the process to an appropriate authentication module. Each > > module extracts the required information in it's own way and > > authenticates the message. > > > > The next step is authorization. Now this is what I'd be more > > interested in. Once I have the authentication, I need to authorize the > > > SOAP request. Here too SAML can be used to set assertions. And then > > again maybe not. So I'd have to have separate modules for > > authorization as well. Each of which relate to internal mappers (what > > are mappers?? Look up DBs??) > > > > This is the basic requirement. The hassle is, I'm new to webservices > > and I was wondering what standards, protocols and APIs I need to work > > with and where they'd fit in. > > > > As far as I see it, (that may not be seeing much) > > WS-Security and SAML could be one of the ways to secure a message and > > that would comprise of one of the many authorization modules I was > > talking about earlier. So I'd need to extract that information from > > the SOAP message and work on it. In order to do that I'd use JAAS > > APIs? (u > > think?) within which I use OpenSAML to work on the extraction? (just > > guessing here..) After extraction I need to map the actors. And that > > should complete the authorization process. > > > > How does that sound? > > > > Dims: > > You had suggested TSIK? I gather they're java APIs for SAML etc.. > > Would that replace JAAS in the above picture? > > > > Regards, > > Nisha > > > > > > -----Original Message----- > > From: Ricky Ho [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 17, 2003 11:40 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: RE: Authorization using WS security and SAML > > > > > > I haven't closely track the OASIS activity. They are supposed to > > standardize how to put a SAML assertion inside a WS-Security header. > > JAAS is a Java API for doing authentication and authorization. > > Compare API with protocol is like oranges and apples. > > > > Rgds, Ricky > > > > At 09:23 AM 3/17/2003 +0530, Nisha Menon wrote: > > >Ricky, > > > > > >Being new to all of this, it's been great help so far already! I've > > >been trying to evaluate the available standards to see what I need to > > > >work with on this module. And from what I've been reading over the > > >last > > > > >month or so, I'd narrowed down to SAML and WS-Security on the basis > > >that they work well together and they're very popular. It'd just been > > > >a > > > > >week since I'd heard about XACML (duh!) and I must admit it had me > > >all confused! :-) thx for helpin me out there! Ok so you've told me > > >about what SAML does (and I guess I can use OpenSAML APIs for > > >development > > >there) but what about WS-Security? Does embedding SAML assertions > into > > >the SOAP Security Header within the <wsse:Security> tag complete the > > >picture? Also, how does JAAS compare to all of these standards in > > >authorization? Where would it fit in? > > > > > >Lotsa questions there! :-( > > > > > >Regards, > > >Nisha > > > > > > > > >-----Original Message----- > > >From: Ricky Ho [mailto:[EMAIL PROTECTED] > > >Sent: Sunday, March 16, 2003 10:08 PM > > >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > >Subject: Re: Authorization using WS security and SAML > > > > > > > > >SAML is about specifying the XML format of your authorization > > >decision outcome (authorization assertion). It also defines a > > >protocol how to request the assertion. SAML doesn't describe how the > > > >decision should be > > > > > >made. XACML is attempting to standardize how such decision rules > > >should be specified. So it is completely solving an orthogonal > > >problem. > > > > > >I'm not sure how important to standardize decision making rules > > >because there is NO "inter-operability" requirement for that. There > > >is NO need > > > > >to communicating how I made my decision to my business partners. The > > > >value of XACML is "portability" of my decision criteria across > > >multiple vendor products. However, "portability" has never been a > > >goal for any XML standard. It is arguable how important XACML will > > >be. > > > > > >Best regards, > > >ricky > > > > > >At 06:38 PM 3/16/2003 +0530, Nisha Menon wrote: > > > >hi, > > > > > > > >i am trying to create an authorization module for web services that > > > > >is independant of the application and to authorize i've chosen to > > > >use > > > > > >WS-Security and SAML. would anyone on this list be familiar with > > > >similar implementation? or > > >have > > > >any references for the same? > > > >also, how does XACML compare to SAML? > > > > > > > >thank you, > > > > > > > >nisha > > > > > > > >**************************Disclaimer******************************* > > > >** > > > >** > > > >* > > > > > > > >Information contained in this E-MAIL being proprietary to Wipro > > > >Limited > > > > > > >is 'privileged' and 'confidential' and intended for use only by the > > > > >individual > > > > or entity to which it is addressed. You are notified that any > > > >use, > > >copying > > > >or dissemination of the information contained in the E-MAIL in any > > >manner > > > >whatsoever is strictly prohibited. > > > > > > > >******************************************************************* > > > >** > > > >** > > > >**** > > > > > > > **************************Disclaimer********************************** > > ** > > > > Information contained in this E-MAIL being proprietary to Wipro > > Limited is 'privileged' and 'confidential' and intended for use only > > by the individual > > or entity to which it is addressed. You are notified that any > > use, copying > > or dissemination of the information contained in the E-MAIL in any > manner > > whatsoever is strictly prohibited. > > > > ****************************************************************** > > ********* > > >
