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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: FW: boolean attributes in SAML 2.0


Folks,

Attached is a question from Andy Sanford from EBSCO regarding boolean attributes.
I've invited Andy to join our SSTC telecon next week, Tuesday March 4th.

Talk to you all on Tuesday.

/thomas/


________________________________________
From: Andy Sanford [asanford@ebsco.com]
Sent: Wednesday, February 26, 2014 2:06 PM
To: ndk@internet2.edu; Thomas Hardjono
Subject: boolean attributes in SAML 2.0

Hello, Nathan and Thomas,

I am contacting you because you are listed as one of the chairs of the OASIS Security Service TC.

Our software acts as a SAML 2.0 SP, and we operate successfully with multiple IdPs.  A question recently came up during our efforts to integrate with a different IdP:

Is it valid for a xsd:Boolean attribute in SAML 2.0 (specifically, the AllowCreate attribute as defined in http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf ) to be encoded as any of the literals {“0”, “1”, “true”,“false”}, or are ONLY the literals {“true”, “false”) valid in the context of SAML 2.0?

Is it possible to get an OASIS opinion on this?  If you’re not the right people to ask, do you know who is?  Any input would be great.


A)     On one side of the argument, it seems since SAML 2.0 is built on XML Schema, and AllowCreate

http://docs.oasis-open.org/security/saml/v2.0/saml-schema-protocol-2.0.xsd


specifically uses XML Schema’s Boolean type:
http://www.w3.org/TR/xmlschema-2/#boolean

that any of the literals {“0”, “1”, “true”,“false”} should be valid.  These 4 literals make up the lexical space of XSD Booleans, and so all 4 literals are valid, and so all 4 should be accepted by any SAML 2.0 compliant SP or IdP.   Furthermore, if standards such as SAML 2.0 build on and leverage the XSD Boolean data type, and if they explicitly refer to Boolean values such as “true” and “false” (such as in section 3.4.1.1 of  http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

“….AllowCreate [Optional]
A Boolean value used to indicate whether the identity provider is allowed, in the course of fulfilling the
request, to create a new identifier to represent the principal. Defaults to "false". When "false", the
requester constrains the identity provider to only issue an assertion to it if an acceptable identifier for
the principal has already been established. Note that this does not prevent the identity provider from
creating such identifiers outside the context of this specific request (for example, in advance for a
large number of principals)…”)

they should be assumed to be referring to the VALUE space of Booleans
http://www.w3.org/TR/xmlschema-2/#value-space

, not the lexical space of Booleans:
http://www.w3.org/TR/xmlschema-2/#lexical-space


B)      The other side of the argument is that the SAML 2.0 standard (such as http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) explicitly describe values of “true” and “false” (see above quote for an example), and so therefore such literals are the only valid ones.

Further examples of such explicit reference to “true” and “false” are here:
http://docs.oasis-open.org/security/saml/v2.0/errata05/os/saml-v2.0-errata05-os.html#__RefHeading__8058_1983180497

http://kantarainitiative.org/confluence/download/attachments/38929505/draft-kantara-egov-saml2-profiles-2.0-01.pdf?version=1&modificationDate=1266525570000&api=v2
“…The <saml2p:AuthnRequest> message SHOULD contain a <saml2p:NameIDPolicy> element with
an AllowCreate attribute of "true"….”



Which interpretation is correct?  Are there documents, standards, comments, guidance, etc. that can be referred to the support a given interpretation? We want to make sure we understand this issue, so we can best facilitate interoperability going forward.



Thanks for your time!



Regards,

-Andy Sanford



Software Architect

EBSCO Information Services



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