Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-4543

Encode multi value claims as multi-value saml attribute

Details

    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.7
    • 3.0.0-milestone1
    • Services
    • None
    • Unknown

    Description

      The current ClaimsAttributeStatementProvider supports encoding for string type value of claims. It's up to the ClaimsHandler to implement multi-value claim support and encoding.

      As mentioned here:
      http://cxf.547215.n5.nabble.com/SAML-2-0-attibutes-and-claims-naming-convention-td5712967.html

      The type of the value in the class Claim has to be changed from String to Object. The ClaimsAttributeStatementProvider can then be configured how to encode multi value claims. Fediz already supports both since FEDIZ-22.

      Attachments

        Issue Links

          Activity

            dkulp Daniel Kulp added a comment -

            I just changed it from String to List<String> and updated the various methods appropriately. Can you verify that that would be adequate? I really prefer the typed collection than a raw object.

            dkulp Daniel Kulp added a comment - I just changed it from String to List<String> and updated the various methods appropriately. Can you verify that that would be adequate? I really prefer the typed collection than a raw object.
            owulff Oliver Wulff added a comment -

            I agree with you with respect to typed collection. A claim value can be a simple type or a list of simple types. The encoded xml element includes the xsi:type.

            Well, the spec also allows complex types:

            1237 The <AttributeValue> element supplies the value of a specified SAML attribute. It is of the
            1238 xs:anyType type, which allows any well-formed XML to appear as the content of the element.
            1239 If the data content of an <AttributeValue> element is of an XML Schema simple type (such as
            1240 xs:integer or xs:string), the datatype MAY be declared explicitly by means of an xsi:type declaration
            1241 in the <AttributeValue> element. If the attribute value contains structured data, the necessary data
            1242 elements MAY be defined in an extension schema.

            I thought the object type provides most flexibility. Initially, we would support basic types and list of basic types in the ClaimsAttributeStatementProvider. If anybody wants to support complex types in custom claimshandler he can do that but only with a more flexible type than List<String>.

            WDYT?

            owulff Oliver Wulff added a comment - I agree with you with respect to typed collection. A claim value can be a simple type or a list of simple types. The encoded xml element includes the xsi:type. Well, the spec also allows complex types: 1237 The <AttributeValue> element supplies the value of a specified SAML attribute. It is of the 1238 xs:anyType type, which allows any well-formed XML to appear as the content of the element. 1239 If the data content of an <AttributeValue> element is of an XML Schema simple type (such as 1240 xs:integer or xs:string), the datatype MAY be declared explicitly by means of an xsi:type declaration 1241 in the <AttributeValue> element. If the attribute value contains structured data, the necessary data 1242 elements MAY be defined in an extension schema. I thought the object type provides most flexibility. Initially, we would support basic types and list of basic types in the ClaimsAttributeStatementProvider. If anybody wants to support complex types in custom claimshandler he can do that but only with a more flexible type than List<String>. WDYT?

            Hi Oli,

            Can this issue be resolved, or is there outstanding work here?

            Colm.

            coheigea Colm O hEigeartaigh added a comment - Hi Oli, Can this issue be resolved, or is there outstanding work here? Colm.
            owulff Oliver Wulff added a comment -

            Right now, everything is encoded as a string even the Attribute type is an integer or something else.
            The Claimshandler should be able to tell the ClaimsAttributeStatementProvider the type of the value (int, ...) which will then result into a properly typed saml Attribute (xsi:type=...).
            We should make this change for 3.0 otherwise we have to wait for 4.0
            WDYT?

            owulff Oliver Wulff added a comment - Right now, everything is encoded as a string even the Attribute type is an integer or something else. The Claimshandler should be able to tell the ClaimsAttributeStatementProvider the type of the value (int, ...) which will then result into a properly typed saml Attribute (xsi:type=...). We should make this change for 3.0 otherwise we have to wait for 4.0 WDYT?

            Hi Oli,

            I merged a fix for this issue, although not quite along the lines you suggested. Opensaml has the option of adding custom AttributeValues via Opensaml "XMLObject" instances. WSS4J's AttributeBean already has an option to allow this via "setCustomAttributeValues(List<?> values)".

            So I added a similar method to the STS's Claim class, and updated the AttributeStatementProvider to set the custom values on the AttributeBean if they are defined. It's up to the ClaimsHandler implementation to create custom XMLObjects using Opensaml. So for example, in a unit test I committed:

            if (ClaimTypes.MOBILEPHONE.equals(requestClaim.getClaimType()))

            { // Test custom (Integer) attribute value XMLObjectBuilderFactory builderFactory = Configuration.getBuilderFactory(); @SuppressWarnings("unchecked") XMLObjectBuilder<XSInteger> xsIntegerBuilder = (XMLObjectBuilder<XSInteger>)builderFactory.getBuilder(XSInteger.TYPE_NAME); XSInteger attributeValue = xsIntegerBuilder.buildObject(AttributeValue.DEFAULT_ELEMENT_NAME, XSInteger.TYPE_NAME); attributeValue.setValue(185912592); claim.setCustomValues(Collections.singletonList(attributeValue)); }

            It's not really possible to define a list of types + then marshal them using Opensaml.

            Colm.

            coheigea Colm O hEigeartaigh added a comment - Hi Oli, I merged a fix for this issue, although not quite along the lines you suggested. Opensaml has the option of adding custom AttributeValues via Opensaml "XMLObject" instances. WSS4J's AttributeBean already has an option to allow this via "setCustomAttributeValues(List<?> values)". So I added a similar method to the STS's Claim class, and updated the AttributeStatementProvider to set the custom values on the AttributeBean if they are defined. It's up to the ClaimsHandler implementation to create custom XMLObjects using Opensaml. So for example, in a unit test I committed: if (ClaimTypes.MOBILEPHONE.equals(requestClaim.getClaimType())) { // Test custom (Integer) attribute value XMLObjectBuilderFactory builderFactory = Configuration.getBuilderFactory(); @SuppressWarnings("unchecked") XMLObjectBuilder<XSInteger> xsIntegerBuilder = (XMLObjectBuilder<XSInteger>)builderFactory.getBuilder(XSInteger.TYPE_NAME); XSInteger attributeValue = xsIntegerBuilder.buildObject(AttributeValue.DEFAULT_ELEMENT_NAME, XSInteger.TYPE_NAME); attributeValue.setValue(185912592); claim.setCustomValues(Collections.singletonList(attributeValue)); } It's not really possible to define a list of types + then marshal them using Opensaml. Colm.
            owulff Oliver Wulff added a comment -

            As this is a major version, we should be able to update the method signature of the Claim class.

            owulff Oliver Wulff added a comment - As this is a major version, we should be able to update the method signature of the Claim class.

            Updated now to be "Object". The object in question can either be a String or an Opensaml XMLObject, for Attributes of different types.

            Colm.

            coheigea Colm O hEigeartaigh added a comment - Updated now to be "Object". The object in question can either be a String or an Opensaml XMLObject, for Attributes of different types. Colm.

            People

              coheigea Colm O hEigeartaigh
              owulff Oliver Wulff
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: