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. > > ****************************************************************** > ********* >
