Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5.2
    • Fix Version/s: 2.5.3
    • Component/s: Services
    • Labels:
    • Estimated Complexity:
      Moderate

      Description

      STS-core:
      Currently there is now way to use a custom dialect in requested claims. Even http://schemas.xmlsoap.org/ws/2005/05/identity/claims is not fully supported (only ClaimType element).

      Therefore I introduced a new Interface ClaimParser, and a DefaultClaimParser with the current parsing logic. This parser is called by default within RequestParser, so that the normal cxf behavior has not changed. But to make this process more flexible it is possible (with this patch) to register any kind of ClaimParser supporting a specific dialect. I implemented a IdentityClaimParser which is currently able to parser CustomType and CustomValueType elements within the wst:claims element. Since the current RequestClaim does not support any claim values, except of the Uri attribute, I created a SubClass ClaimValueType to also pass the claim value to the claim handler.

      This patch is just a starting point. I think there should be a more complex redesign of the current claim handling implementation, because it is currently focused on only one Use-Case. The following improvements should be made:

      • The RequestClaim class should be replaced by a more flexible interface supporting any kind of parsing and handling custom dialects.
      • It should be possible to include/configure custom claimparser via spring config
      • A fully supported implementation of http://schemas.xmlsoap.org/ws/2005/05/identity/claims dialect would be great

      Here is an example of a claims STS request which is supported by applying this patch:
      <wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity" xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">
      <ic:ClaimValue Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"/>admin</ic:ClaimValue>
      </wst:Claims>

      Thank you for this great product!! I hope this patch can help to further improve CXF.

      Best regards
      Jan

      1. cxf-sts-claims.patch
        14 kB
        Jan Bernhardt
      2. cxf-sts-claims.patch
        48 kB
        Jan Bernhardt
      3. claimParer.patch
        40 kB
        Jan Bernhardt

        Activity

        Hide
        Colm O hEigeartaigh added a comment -

        Hi Jan,

        Thanks for your patch.

        >> Even http://schemas.xmlsoap.org/ws/2005/05/identity/claims is not fully supported (only ClaimType element).

        According to the spec: "This profile defines the ic:ClaimType element for use as a child of the wst:Claims element." - it doesn't say anything about ClaimValue, unless I'm missing something.

        I'd prefer to see the following changes to your patch - if you disagree feel free to argue with me

        a) Make the claimParser map in RequestParser configurable - you should be able to spring load different implementations of the ClaimParser interface.
        b) Do not add the IdentityClaimParser as a default parser. As I stated above, I don't believe that it's standard to have ClaimValue children of the wst:Claims Element. Instead, this parser should be configurable.
        c) The dialect of the default claims parser should be the standard namespace.
        d) Please add a test as part of this patch to show how to plug in a custom ClaimParser.

        Thanks,

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi Jan, Thanks for your patch. >> Even http://schemas.xmlsoap.org/ws/2005/05/identity/claims is not fully supported (only ClaimType element). According to the spec: "This profile defines the ic:ClaimType element for use as a child of the wst:Claims element." - it doesn't say anything about ClaimValue, unless I'm missing something. I'd prefer to see the following changes to your patch - if you disagree feel free to argue with me a) Make the claimParser map in RequestParser configurable - you should be able to spring load different implementations of the ClaimParser interface. b) Do not add the IdentityClaimParser as a default parser. As I stated above, I don't believe that it's standard to have ClaimValue children of the wst:Claims Element. Instead, this parser should be configurable. c) The dialect of the default claims parser should be the standard namespace. d) Please add a test as part of this patch to show how to plug in a custom ClaimParser. Thanks, Colm.
        Hide
        Jan Bernhardt added a comment -

        Hi Colm,

        [ https://issues.apache.org/jira/browse/CXF-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218138#comment-13218138 ]

        Colm O hEigeartaigh commented on CXF-4062:
        ------------------------------------------

        Hi Jan,

        Thanks for your patch.

        According to the spec: "This profile defines the ic:ClaimType element for use as a child of the wst:Claims element." - it doesn't say anything about ClaimValue, unless I'm missing something.

        If you have a look into the schema definition you will find ClaimValueType and others.
        http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-errata-os.xsd

        I'd prefer to see the following changes to your patch - if you disagree feel free to argue with me

        a) Make the claimParser map in RequestParser configurable - you should be able to spring load different implementations of the ClaimParser interface.
        I fully agree, I just did not know the best place to do this. How / where would you do this? ClaimParsing happens quite deep in the STS, further changes would be necessary...

        b) Do not add the IdentityClaimParser as a default parser. As I stated above, I don't believe that it's standard to have ClaimValue children of the wst:Claims Element. Instead, this parser should be configurable.
        I just added this Parser as my default parser, since I had no way to configure it via spring, so I got the desired handling by default.

        c) The dialect of the default claims parser should be the standard namespace.
        What is the standard Namespace? http://schemas.xmlsoap.org/ws/2005/05/identity/claims is used in all examples I have seen so far. And for this Namespace my IdentityClaimParser would be a good starting point (since it is not complete according to the schema).

        d) Please add a test as part of this patch to show how to plug in a custom ClaimParser.
        I could do this, after completion of a).

        The RequestClaim class should be replaced by a more flexible interface supporting any kind of custom claim dialects. But this change would have an effect for current ClaimHandler, so this can not be done "silent"...

        Best wishes
        Jan

        Thanks,

        Colm.


        This message is automatically generated by JIRA.
        If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
        For more information on JIRA, see: http://www.atlassian.com/software/jira

        Show
        Jan Bernhardt added a comment - Hi Colm, [ https://issues.apache.org/jira/browse/CXF-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218138#comment-13218138 ] Colm O hEigeartaigh commented on CXF-4062 : ------------------------------------------ Hi Jan, Thanks for your patch. According to the spec: "This profile defines the ic:ClaimType element for use as a child of the wst:Claims element." - it doesn't say anything about ClaimValue, unless I'm missing something. If you have a look into the schema definition you will find ClaimValueType and others. http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-errata-os.xsd I'd prefer to see the following changes to your patch - if you disagree feel free to argue with me a) Make the claimParser map in RequestParser configurable - you should be able to spring load different implementations of the ClaimParser interface. I fully agree, I just did not know the best place to do this. How / where would you do this? ClaimParsing happens quite deep in the STS, further changes would be necessary... b) Do not add the IdentityClaimParser as a default parser. As I stated above, I don't believe that it's standard to have ClaimValue children of the wst:Claims Element. Instead, this parser should be configurable. I just added this Parser as my default parser, since I had no way to configure it via spring, so I got the desired handling by default. c) The dialect of the default claims parser should be the standard namespace. What is the standard Namespace? http://schemas.xmlsoap.org/ws/2005/05/identity/claims is used in all examples I have seen so far. And for this Namespace my IdentityClaimParser would be a good starting point (since it is not complete according to the schema). d) Please add a test as part of this patch to show how to plug in a custom ClaimParser. I could do this, after completion of a). The RequestClaim class should be replaced by a more flexible interface supporting any kind of custom claim dialects. But this change would have an effect for current ClaimHandler, so this can not be done "silent"... Best wishes Jan Thanks, Colm. – This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
        Hide
        Colm O hEigeartaigh added a comment -

        Hi Jan,

        > If you have a look into the schema definition you will find ClaimValueType and others.
        > http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-errata-os.xsd

        Sure, but is it meant to be used as a child of the wst:Claims Element? Can you point me to any examples of this?

        > I fully agree, I just did not know the best place to do this. How / where would you do this? ClaimParsing
        > happens quite deep in the STS, further changes would be necessary...

        You could just add another parameter to RequestParser.parseRequest(...), which is set as a class variable of AbstractOperation, in much the same way as the ClaimsManager can be configured.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi Jan, > If you have a look into the schema definition you will find ClaimValueType and others. > http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-errata-os.xsd Sure, but is it meant to be used as a child of the wst:Claims Element? Can you point me to any examples of this? > I fully agree, I just did not know the best place to do this. How / where would you do this? ClaimParsing > happens quite deep in the STS, further changes would be necessary... You could just add another parameter to RequestParser.parseRequest(...), which is set as a class variable of AbstractOperation, in much the same way as the ClaimsManager can be configured. Colm.
        Hide
        Oliver Wulff added a comment -

        Hi Jan

        Could you give me a little bit background on the use case. Do you want to send some claim values in the RST to the STS to transform this claim values and issue a new SAML token which includes the new claim values in the attributestatement?

        <wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity" xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">
        <ic:ClaimValue Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"/>admin</ic:ClaimValue>
        </wst:Claims>

        Thanks
        Oli

        Show
        Oliver Wulff added a comment - Hi Jan Could you give me a little bit background on the use case. Do you want to send some claim values in the RST to the STS to transform this claim values and issue a new SAML token which includes the new claim values in the attributestatement? <wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity" xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity"> <ic:ClaimValue Uri="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"/>admin</ic:ClaimValue> </wst:Claims> Thanks Oli
        Hide
        Oliver Wulff added a comment -

        Here is an example of another claims dialect which makes use of passing values of a claim.

        <wst:RequestSecurityToken>
        <wst:TokenType>
        ...
        </wst:TokenType>
        <wst:RequestType>
        http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
        </wst:RequestType>
        <wst:Claims
        Dialect="http://schemas.xmlsoap.org/ws/2006/12/authorization/authclaims">
        <auth:ClaimType Uri="http://schemas.xmlsoap.org/claims/Group">
        <auth:Value>Bonded</auth:Value>
        </auth:ClaimType>
        </wst:Claims>
        <auth:AdditionalContext>
        <auth:ContextItem Name="http://www.fabrikam.com/rfps/tracking/for">
        <auth:Value>Contoso</auth:Value>
        </auth:ContextItem>
        <auth:ContextItem Name="http://www.fabrikam.com/rfps/tracking/bidid">
        <auth:Value>t9000hx-1139</auth:Value>
        </auth:ContextItem>
        <auth:ContextItem
        Name="http://www.fabrikam.com/rfps/tracking/value">
        <auth:Value>$1,320,000.00</auth:Value>
        </auth:ContextItem>
        </auth:AdditionalContext>
        </wst:RequestSecurityToken>

        You can find more information here:
        http://msdn.microsoft.com/en-us/library/bb498017.aspx

        Show
        Oliver Wulff added a comment - Here is an example of another claims dialect which makes use of passing values of a claim. <wst:RequestSecurityToken> <wst:TokenType> ... </wst:TokenType> <wst:RequestType> http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue </wst:RequestType> <wst:Claims Dialect="http://schemas.xmlsoap.org/ws/2006/12/authorization/authclaims"> <auth:ClaimType Uri="http://schemas.xmlsoap.org/claims/Group"> <auth:Value>Bonded</auth:Value> </auth:ClaimType> </wst:Claims> <auth:AdditionalContext> <auth:ContextItem Name="http://www.fabrikam.com/rfps/tracking/for"> <auth:Value>Contoso</auth:Value> </auth:ContextItem> <auth:ContextItem Name="http://www.fabrikam.com/rfps/tracking/bidid"> <auth:Value>t9000hx-1139</auth:Value> </auth:ContextItem> <auth:ContextItem Name="http://www.fabrikam.com/rfps/tracking/value"> <auth:Value>$1,320,000.00</auth:Value> </auth:ContextItem> </auth:AdditionalContext> </wst:RequestSecurityToken> You can find more information here: http://msdn.microsoft.com/en-us/library/bb498017.aspx
        Hide
        Colm O hEigeartaigh added a comment -

        Hi Oli,

        Thanks for the example. What are your opinions on points b and c I raised above? The example you posted is using a different dialect. I haven't seen any evidence yet to suggest that the IdentityClaimParser in the patch should ship with the STS.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Hi Oli, Thanks for the example. What are your opinions on points b and c I raised above? The example you posted is using a different dialect. I haven't seen any evidence yet to suggest that the IdentityClaimParser in the patch should ship with the STS. Colm.
        Hide
        Oliver Wulff added a comment -

        Hi Colm
        b) I agree that ClaimValue as a child of Claims is not standard and should not be the default.
        c) The default should be http://schemas.xmlsoap.org/ws/2005/05/identity/claims
        but I'm not 100% sure whether IdentityClaimParser is the claimsparser for this standard namespace
        Thanks
        Oli

        Show
        Oliver Wulff added a comment - Hi Colm b) I agree that ClaimValue as a child of Claims is not standard and should not be the default. c) The default should be http://schemas.xmlsoap.org/ws/2005/05/identity/claims but I'm not 100% sure whether IdentityClaimParser is the claimsparser for this standard namespace Thanks Oli
        Hide
        Jan Bernhardt added a comment -

        Colm O hEigeartaigh commented on CXF-4062:
        ------------------------------------------

        Hi Jan,

        Sure, but is it meant to be used as a child of the wst:Claims Element? Can you point me to any examples of this?

        Correct me if I'm wrong, but as far as I understand the WS-Trust spec:

        • WS-Trust "Claims" element contains an attribute "Dialect" which indicates the type of claims contained in the WS-Trust Claims element.
        • WS-Trust schema definition expects a sequence of ANY elements within Claims element
        • If the dialect is set to "http://schemas.xmlsoap.org/ws/2005/05/identity" than any element defined in this namespace could appear with in WS-Trust Claims element.

        Since the element ClaimValue is defined in "http://schemas.xmlsoap.org/ws/2005/05/identity" namespace the following statement should be valid according to the specifications:

        <sp:RequestSecurityTokenTemplate>
        <t:TokenType>http://...#SAMLV1.1</t:TokenType>
        <t:KeyType>http://.../PublicKey</t:KeyType>
        <t:Claims Dialect="http://.../identity" xmlns:ic="http://.../identity">
        <ic:ClaimValue Uri="http://.../claims/role">administrator</ic:ClaimValue>
        </t:Claims>
        </sp:RequestSecurityTokenTemplate>

        The usecase for this is, that a consumer needs a SAML Token containing only a specific role attribute statement and not a list of all roles assigned to a given user. The STS would have to parse this Claim Request and check (via ClaimHandler) if the user is assigned to the requested role. If this is the case, a SAML Token will be created containing only this specifically requested role.

        In the current version of CXF STS would not be able to parse such a STR, because it only expects a "ic:ClaimType" element within "t:Claims". Which is only a small subset of the dialect "http://schemas.xmlsoap.org/ws/2005/05/identity".

        @Oli Role transformation would not solve this issue, since I do not want to transform a previously requested claim of a token, but instead request convermation for only a specific ClaimValue (here: administrator).

        I hope this subject has become more clear now...

        I'm looking forward for your reply to this message!

        Best regards
        Jan

        Show
        Jan Bernhardt added a comment - Colm O hEigeartaigh commented on CXF-4062 : ------------------------------------------ Hi Jan, Sure, but is it meant to be used as a child of the wst:Claims Element? Can you point me to any examples of this? Correct me if I'm wrong, but as far as I understand the WS-Trust spec: WS-Trust "Claims" element contains an attribute "Dialect" which indicates the type of claims contained in the WS-Trust Claims element. WS-Trust schema definition expects a sequence of ANY elements within Claims element If the dialect is set to "http://schemas.xmlsoap.org/ws/2005/05/identity" than any element defined in this namespace could appear with in WS-Trust Claims element. Since the element ClaimValue is defined in "http://schemas.xmlsoap.org/ws/2005/05/identity" namespace the following statement should be valid according to the specifications: <sp:RequestSecurityTokenTemplate> <t:TokenType> http://...#SAMLV1.1 </t:TokenType> <t:KeyType> http://.../PublicKey </t:KeyType> <t:Claims Dialect="http://.../identity" xmlns:ic="http://.../identity"> <ic:ClaimValue Uri="http://.../claims/role">administrator</ic:ClaimValue> </t:Claims> </sp:RequestSecurityTokenTemplate> The usecase for this is, that a consumer needs a SAML Token containing only a specific role attribute statement and not a list of all roles assigned to a given user. The STS would have to parse this Claim Request and check (via ClaimHandler) if the user is assigned to the requested role. If this is the case, a SAML Token will be created containing only this specifically requested role. In the current version of CXF STS would not be able to parse such a STR, because it only expects a "ic:ClaimType" element within "t:Claims". Which is only a small subset of the dialect "http://schemas.xmlsoap.org/ws/2005/05/identity". @Oli Role transformation would not solve this issue, since I do not want to transform a previously requested claim of a token, but instead request convermation for only a specific ClaimValue (here: administrator). I hope this subject has become more clear now... I'm looking forward for your reply to this message! Best regards Jan
        Hide
        Oliver Wulff added a comment -

        I guess I understand. The user can work with your application in different roles (administrator,user) but only with one role at the time. When the SAML token is requested, the user must have decided for a role in which context he wants to work with the application. Your ClaimsHandler must have to verify that the user has really assigned this role. Is this correct?

        You agree that there is no new claims dialect required because "http://schemas.xmlsoap.org/ws/2005/05/identity" can cover your requirements:

        <xs:element name="ClaimValue" type="tns:ClaimValueType"/>
        <xs:complexType name="ClaimValueType">
        <xs:complexContent>
        <xs:extension base="tns:BaseClaimType">
        <xs:sequence>
        <xs:element name="Value" type="tns:StringMaxLength684"/>
        </xs:sequence>
        </xs:extension>
        </xs:complexContent>
        </xs:complexType>

        The ClaimValueType is a sub-type of BaseClaimType.

        What do you think about the introduction of a subclass of RequestClaimValue or add set/getClaimValue to the RequestClaim class. This would work for 2.5.x too.

        Could you also add a testcase for this new feature?

        Show
        Oliver Wulff added a comment - I guess I understand. The user can work with your application in different roles (administrator,user) but only with one role at the time. When the SAML token is requested, the user must have decided for a role in which context he wants to work with the application. Your ClaimsHandler must have to verify that the user has really assigned this role. Is this correct? You agree that there is no new claims dialect required because "http://schemas.xmlsoap.org/ws/2005/05/identity" can cover your requirements: <xs:element name="ClaimValue" type="tns:ClaimValueType"/> <xs:complexType name="ClaimValueType"> <xs:complexContent> <xs:extension base="tns:BaseClaimType"> <xs:sequence> <xs:element name="Value" type="tns:StringMaxLength684"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> The ClaimValueType is a sub-type of BaseClaimType. What do you think about the introduction of a subclass of RequestClaimValue or add set/getClaimValue to the RequestClaim class. This would work for 2.5.x too. Could you also add a testcase for this new feature?
        Hide
        Jan Bernhardt added a comment -

        [ https://issues.apache.org/jira/browse/CXF-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223133#comment-13223133 ]

        Oliver Wulff commented on CXF-4062:
        -----------------------------------

        I guess I understand. The user can work with your application in different roles (administrator,user) but only with one role at the time. When the SAML token is requested, the user must have decided for a role in which context he wants to work with the application. Your ClaimsHandler must have to verify that the user has really assigned this role. Is this correct?

        Yes, this is correct!!
        I finally got understood

        You agree that there is no new claims dialect required because "http://schemas.xmlsoap.org/ws/2005/05/identity" can cover your requirements:

        This was my point from the very beginning!
        I do not need a new Dialect, just CXF is currently not able to fully support this identity dialect. That’s where the idea of my patch came from...

        <xs:element name="ClaimValue" type="tns:ClaimValueType"/> <xs:complexType name="ClaimValueType">
        <xs:complexContent>
        <xs:extension base="tns:BaseClaimType">
        <xs:sequence>
        <xs:element name="Value" type="tns:StringMaxLength684"/>
        </xs:sequence>
        </xs:extension>
        </xs:complexContent>
        </xs:complexType>

        The ClaimValueType is a sub-type of BaseClaimType.

        What do you think about the introduction of a subclass of RequestClaimValue or add set/getClaimValue to the RequestClaim class. This would work for 2.5.x too.

        This is what I did in my provided patch, to ensure backwards compatibility. But I think this behavior is still not a good design, since WS-Trust would allow one to use any kind of dialects, even those not providing a ClaimType URI.
        So my suggestion would be to introduce a new Claim Interface to be more flexible for any kind of claims.

        Could you also add a testcase for this new feature?

        Yes, I try to get this done within next couple of days.

        Best regards
        Jan

        Show
        Jan Bernhardt added a comment - [ https://issues.apache.org/jira/browse/CXF-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223133#comment-13223133 ] Oliver Wulff commented on CXF-4062 : ----------------------------------- I guess I understand. The user can work with your application in different roles (administrator,user) but only with one role at the time. When the SAML token is requested, the user must have decided for a role in which context he wants to work with the application. Your ClaimsHandler must have to verify that the user has really assigned this role. Is this correct? Yes, this is correct!! I finally got understood You agree that there is no new claims dialect required because "http://schemas.xmlsoap.org/ws/2005/05/identity" can cover your requirements: This was my point from the very beginning! I do not need a new Dialect, just CXF is currently not able to fully support this identity dialect. That’s where the idea of my patch came from... <xs:element name="ClaimValue" type="tns:ClaimValueType"/> <xs:complexType name="ClaimValueType"> <xs:complexContent> <xs:extension base="tns:BaseClaimType"> <xs:sequence> <xs:element name="Value" type="tns:StringMaxLength684"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> The ClaimValueType is a sub-type of BaseClaimType. What do you think about the introduction of a subclass of RequestClaimValue or add set/getClaimValue to the RequestClaim class. This would work for 2.5.x too. This is what I did in my provided patch, to ensure backwards compatibility. But I think this behavior is still not a good design, since WS-Trust would allow one to use any kind of dialects, even those not providing a ClaimType URI. So my suggestion would be to introduce a new Claim Interface to be more flexible for any kind of claims. Could you also add a testcase for this new feature? Yes, I try to get this done within next couple of days. Best regards Jan
        Hide
        Colm O hEigeartaigh added a comment -

        > What do you think about the introduction of a subclass of RequestClaimValue or add set/getClaimValue to the > RequestClaim class. This would work for 2.5.x too.

        +1 to this. This would support your use-case with no additional work. The second task would be to add the ClaimsParser and DefaultClaimsParser implementation as per your original patch to implement the current parsing behaviour, and make it pluggable.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - > What do you think about the introduction of a subclass of RequestClaimValue or add set/getClaimValue to the > RequestClaim class. This would work for 2.5.x too. +1 to this. This would support your use-case with no additional work. The second task would be to add the ClaimsParser and DefaultClaimsParser implementation as per your original patch to implement the current parsing behaviour, and make it pluggable. Colm.
        Hide
        Oliver Wulff added a comment -

        >>>
        This is what I did in my provided patch, to ensure backwards compatibility. But I think this behavior is still not a good design, since WS-Trust would allow one to use any kind of dialects, even those not providing a ClaimType URI.
        >>>
        Initially, I'll add a new method to RequestClaim and update RequestParser to provide the value to your ClaimsHandler. This can be back-ported to 2.5.x.

        For 2.6, let's focus in adding a generic interface for custom claims parsing. Should there be a common interface for the one who retrieves the claims (like ClaimsAttributeStatementProvider) or will this implementation be claims parser dependent?

        Show
        Oliver Wulff added a comment - >>> This is what I did in my provided patch, to ensure backwards compatibility. But I think this behavior is still not a good design, since WS-Trust would allow one to use any kind of dialects, even those not providing a ClaimType URI. >>> Initially, I'll add a new method to RequestClaim and update RequestParser to provide the value to your ClaimsHandler. This can be back-ported to 2.5.x. For 2.6, let's focus in adding a generic interface for custom claims parsing. Should there be a common interface for the one who retrieves the claims (like ClaimsAttributeStatementProvider) or will this implementation be claims parser dependent?
        Hide
        Oliver Wulff added a comment -

        Compared to your example above, the value of the claim is set within the child element "Value" of "ClaimValue" and not as the content.

        The correct example should be:

        <sp:RequestSecurityTokenTemplate>
        <t:TokenType>http://...#SAMLV1.1</t:TokenType>
        <t:KeyType>http://.../PublicKey</t:KeyType>
        <t:Claims Dialect="http://.../identity" xmlns:ic="http://.../identity">
        <ic:ClaimValue Uri="http://.../claims/role">
        <ic:Value>administrator</ic:Value>
        </ic:ClaimValue>
        </t:Claims>
        </sp:RequestSecurityTokenTemplate>

        Show
        Oliver Wulff added a comment - Compared to your example above, the value of the claim is set within the child element "Value" of "ClaimValue" and not as the content. The correct example should be: <sp:RequestSecurityTokenTemplate> <t:TokenType> http://...#SAMLV1.1 </t:TokenType> <t:KeyType> http://.../PublicKey </t:KeyType> <t:Claims Dialect="http://.../identity" xmlns:ic="http://.../identity"> <ic:ClaimValue Uri="http://.../claims/role"> <ic:Value>administrator</ic:Value> </ic:ClaimValue> </t:Claims> </sp:RequestSecurityTokenTemplate>
        Hide
        Jan Bernhardt added a comment -

        [ https://issues.apache.org/jira/browse/CXF-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223651#comment-13223651 ]

        Oliver Wulff commented on CXF-4062:
        -----------------------------------

        Compared to your example above, the value of the claim is set within the child element "Value" of "ClaimValue" and not as the content.

        Yes, your are right!

        The correct example should be:

        <sp:RequestSecurityTokenTemplate>
        <t:TokenType>http://...#SAMLV1.1</t:TokenType>
        <t:KeyType>http://.../PublicKey</t:KeyType>
        <t:Claims Dialect="http://.../identity" xmlns:ic="http://.../identity">
        <ic:ClaimValue Uri="http://.../claims/role">
        <ic:Value>administrator</ic:Value>
        </ic:ClaimValue>
        </t:Claims>
        </sp:RequestSecurityTokenTemplate>

        Show
        Jan Bernhardt added a comment - [ https://issues.apache.org/jira/browse/CXF-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13223651#comment-13223651 ] Oliver Wulff commented on CXF-4062 : ----------------------------------- Compared to your example above, the value of the claim is set within the child element "Value" of "ClaimValue" and not as the content. Yes, your are right! The correct example should be: <sp:RequestSecurityTokenTemplate> <t:TokenType> http://...#SAMLV1.1 </t:TokenType> <t:KeyType> http://.../PublicKey </t:KeyType> <t:Claims Dialect="http://.../identity" xmlns:ic="http://.../identity"> <ic:ClaimValue Uri="http://.../claims/role"> <ic:Value>administrator</ic:Value> </ic:ClaimValue> </t:Claims> </sp:RequestSecurityTokenTemplate>
        Hide
        Oliver Wulff added a comment -

        Raised a new JIRA CXF-4173 to track support for ClaimValue element support

        Show
        Oliver Wulff added a comment - Raised a new JIRA CXF-4173 to track support for ClaimValue element support
        Hide
        Jan Bernhardt added a comment - - edited

        Here is another patch for cxf sts claim parsing. It is based on cxf version 2.6.0-SNAPSHOT.

        Main changes to previously provided patch is, that now claim parser can be registered as part of ClaimManager. If a ClaimsParser is set and a dialect it supports needs to be parsed, this parser will automatically be used. If not, the default implementation from cxf will be called...

        I will provide a JUnit Test case for this hopefully by tomorrow.

        I'm excited for your feedback.

        Show
        Jan Bernhardt added a comment - - edited Here is another patch for cxf sts claim parsing. It is based on cxf version 2.6.0-SNAPSHOT. Main changes to previously provided patch is, that now claim parser can be registered as part of ClaimManager. If a ClaimsParser is set and a dialect it supports needs to be parsed, this parser will automatically be used. If not, the default implementation from cxf will be called... I will provide a JUnit Test case for this hopefully by tomorrow. I'm excited for your feedback.
        Hide
        Jan Bernhardt added a comment -

        Since there is no change to the ClaimHandling Interface, this patch should also work in cxf version 2.5.x just fine...

        Show
        Jan Bernhardt added a comment - Since there is no change to the ClaimHandling Interface, this patch should also work in cxf version 2.5.x just fine...
        Hide
        Colm O hEigeartaigh added a comment -

        Looks ok to me. Why not just use a DefaultClaimsParser implementation to handle the current logic?

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Looks ok to me. Why not just use a DefaultClaimsParser implementation to handle the current logic? Colm.
        Hide
        Jan Bernhardt added a comment -

        Colm O hEigeartaigh commented on CXF-4062:
        ------------------------------------------

        I tried to minimize my changes to cxf code. But of course the handling of claims would be more consistent by providing a DefaultClaimsParser.
        Should I add such an Implementation to my patch?

        Best regards
        Jan

        Show
        Jan Bernhardt added a comment - Colm O hEigeartaigh commented on CXF-4062 : ------------------------------------------ I tried to minimize my changes to cxf code. But of course the handling of claims would be more consistent by providing a DefaultClaimsParser. Should I add such an Implementation to my patch? Best regards Jan
        Hide
        Jan Bernhardt added a comment -

        OK I've got all the requested changes done (at least I think so, correct me if I'm wrong).

        This patch now contains all the changes required to enable custom claim parsing and handling. I've also provided some JUnit Test to show the use of this new feature.

        It would be great to see this changes applied to the next CXF release! If there is some further (minor) work to be done for this patch, I would be willing to contribute this also.

        Show
        Jan Bernhardt added a comment - OK I've got all the requested changes done (at least I think so, correct me if I'm wrong). This patch now contains all the changes required to enable custom claim parsing and handling. I've also provided some JUnit Test to show the use of this new feature. It would be great to see this changes applied to the next CXF release! If there is some further (minor) work to be done for this patch, I would be willing to contribute this also.

          People

          • Assignee:
            Colm O hEigeartaigh
            Reporter:
            Jan Bernhardt
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development