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
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).
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>
I think something similar we could do in CXF and maybe integrate with spring
security.
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
