[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.. Cheers Colin -----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 -----BEGIN PGP SIGNED MESSAGE----- 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7elZMACgkQ8Jx8FtbMZnevDgCgirUasqZXjWHzoe34jDiPemDK FPcAnjIx1QBOPTru+mZFzv1NePnWZ6lh =oIfl -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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]