Folks,
I'd be much happier if someone did demonstrate the X.500->SAML
attribute mapping. IMO, this is an interop issue and so might
justify holding 1.0 (mind you, I'm not sure how interop features
on the 1.0 exit criteria, so maybe I'm wrong there). OTOH, it
shouldn't be that hard to fix either (just add some X.500->
SAML attribute mapping rules to the core doc.)
To demonstrate: say if productX's PDP maps from (inventing syntax
here) inetOrgPerson:commonName to Xsaml-attr:XCommonName and
productY's PEP expects Ysaml-attr:YCommonName then managing access
is difficult for the particular case that SAML was mainly designed
to handle - that is cross domain hand-off.
That's why I'd favor the DSML approach, since (I believe, but
don't know for sure), it means two SAML codebases will both
handle inetOrgPerson attributes in the same way. I'd also argue
that supporting (some) inetOrgPerson attributes be a MUST, but I
guess that's another issue.
I've no problem at all with there being a way to include attribute
syntaxes which are fancier than X.500 allows (though I can't for
the life of me imagine such a beast being useful, given that
an X.500 attribute is basically a bucket of whatever you're having
yourself!). What I want is that different vendors PDPs and PEPs
can work together, and a common understanding of, in particular,
some basic inetOrgPerson attributes is crucial to this IMO.
Regards,
Stephen.
RL 'Bob' Morgan wrote:
>
> On Wed, 23 Jan 2002, Stephen Farrell wrote:
>
> > Did I miss the justification for re-inventing another xml flavor of
> > the ASN.1 Attribute rather than re-using someone else's (e.g. DSML)?
> > Seems like we're re-visiting a lot that others must have considered.
>
> As Scott said, SAML Attributes and values need not be restricted to those
> supported in LDAP/X.500 or definable in ASN.1; in fact I think it's one of
> the points of SAML being XML-oriented to not be so limited. However, I'm
> sure it's the case that many deployments will want to map directly from
> X.500-defined attributes and values to SAML ones (we've talked about this
> quite a bit in Shib), so it would most likely be a useful thing for
> someone to describe a way of doing this, and this would almost certainly
> be based on DSML. But I wouldn't hold up the 1.0 spec waiting on this.
>
> - RL "Bob"
--
____________________________________________________________
Stephen Farrell
Baltimore Technologies, tel: (direct line) +353 1 881 6716
39 Parkgate Street, fax: +353 1 881 7000
Dublin 8. mailto:
Ireland http://www.baltimore.com
