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: RE: [security-services] Best practice for embedding complex trees into SAML attributes

<<Alternatively, shove the complete SCIM document in the SAML AttributeValue.....>>
I'm in no way an expert but my 'in-expert' thought was that this alternative might be better for 'tokenization', for those deploying that approach.

Also, I do hope SCIM did not make up the mane/address/email format. OASIS CIQ does this well already - we need another address schema in the world like a hole in the head..

-----Original Message-----
From: security-services@lists.oasis-open.org [mailto:security-services@lists.oasis-open.org] On Behalf Of Leif Johansson
Sent: Wednesday, 7 December 2011 11:22 a.m.
To: security-services@lists.oasis-open.org
Subject: Re: [security-services] Best practice for embedding complex trees into SAML attributes

Hash: SHA1

On 12/06/2011 07:57 PM, Paul Madsen wrote:
> Hi all, I'm working on a SAML binding for SCIM (simplecloud.info)
> - enabling JIT provisioning as an alternative to the SCIM
> provisioning API.
> The challenge is mapping the (relatively) complex SCIM schema
> constructs into SAML's attributes.

The only way to implement that would be to shove the Name attribute
into an XPath implementation and the result might be very exciting
to debug - XPath just includes too many "features" that could trip you
up and trying to limit yourself to a subset would just defeat the
purpose of using XPath in the first place.

Isn't it better to go for a simpler document/information model and
map directly to attributes? Your only "difficult" issue is how to
handle addresses, right? And those could perhaps be compound values
of some sort. I think LDAP already introduced '$' separated lists
of address components back in the day for that very purpose.

In earlier lives I was involved in similar information modeling
exercise using RDF/OWL for IDM and to put it simply: the market
wasn't ready a level of complexity that went beyond very simple
lists of attribute-value pairs.

	Cheers Leif
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


To unsubscribe, e-mail: security-services-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: security-services-help@lists.oasis-open.org

CAUTION:  This email message and any attachments contain information that may be confidential and may be LEGALLY PRIVILEGED. If you are not the intended recipient, any use, disclosure or copying of this message or attachments is strictly prohibited. If you have received this email message in error please notify us immediately and erase all copies of the message and attachments. Thank you.

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