Hi On Tue, May 17, 2011 at 7:09 PM, Oliver Wulff <[email protected]> wrote: >>>> > 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... >>>> > > I wanted to say this in the following section of the jira description: >>>> > In addition to that, the SamlClaimsTransformer can provide a property to > define the URI how the role information is identified in the > AttributeStatement. There is no standard claims URI for roles. Each STS uses > a different URI. For instance, Microsoft ADFS uses the following URI: > http://schemas.microsoft.com/ws/2008/06/identity/claims/role > This would allow an application to use RBAC when they use ADFS and CXF > out-of-the-box by using the isUserInRole of the WebServiceContext. >>>> > > Or do I misunderstand you? > It may be I haven't read the JIRA description properly. I see that SamlClaimsTransformer is the entity which can build SAML ClaimSecurityContext. I guess I just went into the impl details too early. What I was saying, given that some entity needs to initiate the creation of SAML ClaimSecurityContext, is that that entity needs to have this property set and then that entity (SamlClaimsTransformer for ex) pass this property further to ClaimSecurityContext impl, alongside the complete list of Claims. The latter will simply use this property to figure which claim to use for RBAC.
So I guess I've repeated what you've already said :-). Perhaps you are seeing the process of the initialization differently but I reckon we are on the same page :-) Thanks, Sergey > Thanks > Oli > > > ________________________________________ > Von: Sergey Beryozkin [[email protected]] > Gesendet: Dienstag, 17. Mai 2011 16:02 > An: [email protected] > Betreff: Re: CXF and spring security > > 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
