Hi Oliver I hope to add a rt/security module as soon as I finish with the initial WADL to java code generator work and then Colm or myself can add a token parser. Your summary in CXF-3522 is perfect.
We don't have to wait for the introduction of rt/security if the work needs to be started say this week, SAML token parsing and ClaimSecurityContext code can be added to ws/security right now and I will push it to rt/security once I'm ready but I do plan to start focusing on security for the JAX-RS project very soon, in a couple of weeks or so. It does look like, from CXF-3522, that we can get a solution which will work for JAX-WS and also JAX-RS. Perhaps we can have a claim URI identifying a role Claim injected as a property which will end up being set on ClaimSecurityContext for it to figure out which Claim can be used to initialize a default SecurityContext. I guess a role-based Claim should also be returned as part of the list of Claims as well... thanks, Sergey On Mon, May 16, 2011 at 3:28 PM, Oliver Wulff <[email protected]> wrote: > I've raised JIRA: > https://issues.apache.org/jira/browse/CXF-3522 > > > > Thanks > > Oli > > ________________________________________ > Von: Sergey Beryozkin [[email protected]] > Gesendet: Mittwoch, 4. Mai 2011 14:18 > An: [email protected] > Betreff: Re: CXF and spring security > > 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 >>> >> > -- Sergey Beryozkin Application Integration Division of Talend http://sberyozkin.blogspot.com
