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: Re: [saml-dev] is the "xsi:type" mandatory to be present for theAttributeValue in a SAML Response

Yes, the schema instance datatype is optional.

I personally think it's good practice to include them so as to give a
hint to the receiver about what to expect in the field (and if they
ignore it, that's fine too).

And the OpenSAML library, at least any supported version, can parse
<AttributeValue>s without a specified datatype.

On Wed, Jun 1, 2011 at 04:21, bhaskar jain <bhaskar.jain2002@gmail.com> wrote:
> 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: saml-dev-help@lists.oasis-open.org

Chad La Joie
trusted identities, delivered

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