Hi Oliver Thanks for this information, very interesting, please see comments inline
On Wed, May 4, 2011 at 10:30 AM, Oliver Wulff <[email protected]> wrote: > Hi Sergey > >>>> > Can some of the claims be used for servicing isUserInRole calls ? This is > something I have to catch up with, but looking say at [2] suggests that the > sample token there can be used for asserting isUserInRole("staff") ? > >>>> > > As far as I know, there is no standard claim for role. For example, WIF > allows you to configure the URI of the claim which contains the role > information. > > > >>>> > > What other types of claims can be used and how in principle they can be used > for authorizing the access to a given service method ? > >>>> > > The following specification standardizes a lot of claim URIs like lastname, > country, etc (chapter 7.5): > > http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.pdf > thanks for the link. OK, so a number of claim URIs can be used, custom ones if needed. I've looked again at http://en.wikipedia.org/wiki/SAML_1.1, the Attribute namespace is using Shibboleth namespace (http://en.wikipedia.org/wiki/Shibboleth_(Internet2) and it has a value "member" > IMHO, traditionally, authorization has been built within the application code > around the user name. Usually, the RBAC doesn't fulfill fine-grained > authorization. The application logic has read the username and accessed some > sort of identity system (in worst case application specific) to get more > information about the user like in which country it is, which age it has, > etc. Fine grained access control is done based on this information and not on > the username. If there are not too many options for the value of a claim I've > seen a mapping to roles like. This can become quite difficult to manage if > some roles exclude each other. Example: the application needs to know in > which country the user lives and from which B2B partner. Roles could look > like DE_Broker, DE_XYZ and others for UK_Broker, UK_ABC, UK_DEF. (difficult > if you try to map multi-dimensions to single dimension). > OK, I understand, this is much richer than RBAC. > > > To me, the solution is STS and the option to put such kind of claims > information into a SAML token. Here is an example of such an attribute > statement: > > > > <AttributeStatement><Attribute > Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname";><AttributeValue>John</AttributeValue></Attribute><Attribute > > Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname";><AttributeValue>Doe</AttributeValue></Attribute><Attribute > > Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth";><AttributeValue>5/5/1955</AttributeValue></Attribute><Attribute > > Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone";><AttributeValue>555-555-5555</AttributeValue></Attribute><Attribute > > Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress";><AttributeValue>[email protected]</AttributeValue></Attribute><Attribute > > Name="http://cloudbuddies.com/2009/06/FrequentFlyerProgram";><AttributeValue>ContosoAir</AttributeValue></Attribute>AttributeStatement> > thanks for this example, it's helpful > > > I think something similar we could do in CXF and maybe integrate with spring > security. > > +1 to CXF supporting more complex fine-grained authorization logic. That will be great. The reason I'm looking into how isUserInRole can be satisfied is that this is what many users do/rely upon for a simple (compared to the richness of arbitrary claims) authorization. I hoping though that we will be able to use SAML tokens, when feasible, for making the existing RBAC logic to work too, ex, so that say EJB authorization can work, etc, and other existing configs relying on RBAC. Example, we can attempt to reuse claim definitions such as "member of staff"/etc, providing a CXF specific claim URI if needed. But again - agree we should get the richer authorization working too. Also, about spring security: I hope that if we get an advanced SAMLSecurityContext implemented then those who do not use Spring can also benefit, example, CXF is integrated with higher level containers which do not use Spring at all, so, as long as we have our advanced context available on the current message, after SAML token has been validated and parsed, all 'parties' will be able to use it :-) Thanks, Sergey > > Thanks > > Oli > > ________________________________________ > Von: Sergey Beryozkin [[email protected]] > Gesendet: Dienstag, 3. Mai 2011 23:10 > An: [email protected] > Betreff: Re: CXF and spring security > > Hi Oliver > > On Tue, May 3, 2011 at 9:12 PM, Oliver Wulff <[email protected]> wrote: >> Hi there >> >> CXF 2.4 has a lot of security enhancements in supporting additional security >> tokens like Saml2 and BinarySecurityTokens etc. >> >> IMHO, the service developer should not care what kind of security token has >> been sent by a caller to figure out who called him. JAX-WS defines the >> WebServiceContext to provide some basic information like principal of the >> caller and whether the caller is in a specific role or not. >> >> WS-Federation and WS-Trust provides much more options where the security >> token requestor can ask to put some specific claims into the issued security >> token - represented as an attribute statement in a saml token. >> >> Microsoft provides a flexible and extensible framework called Windows >> Identity Foundation [1] which allows to decouple the application code, the >> authorization logic and the security tokens sent on the wire and. >> >> First, I'm not an expert in spring security but it allows more fine grained >> authorization functionality than isUserInRole. But it needs the claims >> statements made by a third party like an STS. >> >> Wouldn't it make sense to somehow set up the spring security context within >> a CXF interceptor based on the claims made in a saml token? >> >> A claim consists of: >> ClaimType: URI, Namespace which tells you what the value of the claims mean >> Issuer: who issued the claim, usually an STS >> Value: value of the claim >> ValueType: type information >> >> Don't know whether spring security already has a java bean for that. >> >> What is your take on this? >> > > Can some of the claims be used for servicing isUserInRole calls ? This > is something I have to catch up with, but looking say at [2] suggests > that the sample token there can be used for asserting > isUserInRole("staff") ? > > What other types of claims can be used and how in principle they can > be used for authorizing the access to a given service method ? > > thanks, Sergey > > [2] http://en.wikipedia.org/wiki/SAML_2.0 > >> Thanks >> Oli >> >> [1] http://msdn.microsoft.com/en-us/library/ee748484.aspx >> > > > > -- > Sergey Beryozkin > > Application Integration Division of Talend > http://sberyozkin.blogspot.com >
