OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: is the "xsi:type" mandatory to be present for the AttributeValue in aSAML Response


Hi Scott,

We are a SAML 2.0 Identity Provider supporting only the HTTP Post
binding (web browser SSO).
The generated SAML response for a particular case looks like this :-

<saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml:Attribute Name="email">
    <saml:AttributeValue>bar@cisco.com</saml:AttributeValue>
    <saml:AttributeValue>baz@ironport.com</saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>


The response from Ping Federate looks like this :-

   <saml:AttributeStatement xmlns:xs="http://www.w3.org/2001/XMLSchema";>
      <saml:Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
Name="email">
        <saml:AttributeValue
xsi:type="xs:string">bar@cisco.com</saml:AttributeValue>
        <saml:AttributeValue
xsi:type="xs:string">baz@ironport.com</saml:AttributeValue>
       </saml:Attribute>
    </saml:AttributeStatement>



Note that the PingFederate's AttributeValue has a "xsi:type" which we
don't have.
Now the SP is claiming that it cannot process our response because of
the missing datatype. They are using OpenSAML library and they are
unable to parse the response.
If I read the saml-core documents correctly, it implies that the
datatype is optional in case the type is string or integer (.. "the
datatype MAY be declared explicitly" .. )


<AttributeValue> [Any Number]
Contains a value of the attribute. If an attribute contains more than
one discrete value, it is
RECOMMENDED that each value appear in its own <AttributeValue>
element. If more than
one <AttributeValue> element is supplied for an attribute, and any of
the elements have a
datatype assigned through xsi:type, then all of the <AttributeValue>
elements must have
the identical datatype assigned.


Element <AttributeValue>

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

Note: Specifying a datatype other than an XML Schema simple type on
<AttributeValue> using xsi:type will require the presence of the
extension schema
that defines the datatype in order for schema processing to proceed.
If a SAML attribute includes an empty value, such as the empty string,
the corresponding
<AttributeValue> element MUST be empty (generally this is serialized
as <AttributeValue/>).
This overrides the requirement in Section 1.3.1 that string values in
SAML content contain at least one
non-whitespace character.
If a SAML attribute includes a "null" value, the corresponding
<AttributeValue> element MUST be
empty and MUST contain the reserved xsi:nil XML attribute with a value
of "true" or "1".




Is our SAML response syntactically correct and can you please confirm
that the issue lies on the SP side.
Thanks for your help as always.

--
With best regards,
Bhaskar.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]