Hi Oliver On Wed, May 4, 2011 at 12:10 PM, Oliver Wulff <[email protected]> wrote: > Hi Sergey > >>>> > 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. > >>>> > I think this is feasible. CXF could support the following attribute > statements in a SAML 1.1/2.0 token: > > > > <AttributeStatement> > > <Attribute Name="to<http://examples/roles> be configured"> > > <AttributeValue>Administrator</AttributeValue></Attribute> > > <AttributeValue>Manager</AttributeValue></Attribute> > > </Attribute> > > </AttributeStatement> > >
Nice, that should definitely work. > > This means that the application configures the attribute name and CXF is able > to set up the security context to allow isUserInRole etc. > > > > When we talk about STS and WS-SecurityPolicy, the service provider could > express in the WS-SecurityPolicy what kind of claims he need about the > subject. This brings a lot of flexibility. The STS must be able to process > the Claims element and issue the SAML token with the proper attribute > statement. > > > > > >>>> > > 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 :-) >>>> > > Absolutely, I wouldn't name it as the underlying token because it doesn't > matter at the end what kind of token it is. It name it something like > ClaimSecurityContext. The responsible token processor (maybe customizable) > can fill the information into this context. > You are totally right re the token 'neutrality'. Perhaps ClaimSecurityContext can extend the default SecurityContext which provides RBAC rules ? Suppose we have a (SAML) token with few claims, where one of them can be used for isUserInRole. So that particular claim will be used to init the superclass and ClaimSecurityContext will keep all the claims. If no 'RBAC' related claim is available then it will just return false if/when its isUserInRole method is called It may also has a method like isClaimMet(String claimValue) (or whatever method name is appropriate) that can be used for simple checks, as well as more compex isClaimMet(ClaimExpression claim) so that we can get a combination of and/or checks done too. Given those two methods (and more if needed) we can have a CXF interceptor which will get ClaimSecurityContext and enforce the rules. This will work for JAX-RS too which is what I'm really after :-) but a bit more work will need to be done there first. > > > Windows Identity Foundation has choosen this approach which is in line with > the semantic of WS-Trust and WS-Federation. > > thanks, Sergey > > thanks > > Oli > > > > > ________________________________________ > Von: Sergey Beryozkin [[email protected]] > Gesendet: Mittwoch, 4. Mai 2011 12:18 > An: [email protected] > Betreff: Re: CXF and spring security > > 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 >> >
