[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
On Wed, Jun 1, 2011 at 5:43 PM, Chad La Joie <lajoie@itumi.biz> wrote: > 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 > www.itumi.biz > trusted identities, delivered > > --------------------------------------------------------------------- > To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: saml-dev-help@lists.oasis-open.org > > Thanks for the reply. -- With best regards, Bhaskar.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]