[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [saml-dev] Comments on draft-catalyst-interop-plan-01
Irving - Regarding you comments/question below: we at Sigaba absolutely depend on having the email address in the assertion. If we don't have it in the authentication statement then it must come in an attribute statement. I would be difficult for us to build the email address from a DN. Thanks, Jahan >The <NameIdentifier> element in the AuthenticationStatement > will used > > with the format "#emailAddress" with attribute NameQualifier set to > > the vendors name (e.g. "netegrity.com"). In other words, each user > > will be described as joe@address.com, ravi@someaddress.com, > > alice@someaddress.com etc. > > We normally use the LDAP DN for <NameIdentifier>, and it > would be quite a bit of work for us to change. Is anyone not > capable of handling incoming assertions that contain DNs > instead of email addresses? If not, I'd like to remove this > restriction. --------------------------- Jahan Moreh Chief Security Architect tel: 310.286.3070 fax: 310.286.3076 > -----Original Message----- > From: Irving Reid [mailto:Irving.Reid@baltimore.com] > Sent: Tuesday, May 14, 2002 5:15 PM > To: 'Philpott, Robert'; 'Mishra, Prateek'; > saml-dev@lists.oasis-open.org > Subject: [saml-dev] Comments on draft-catalyst-interop-plan-01 > > > 1.2 URL Naming Conventions: > > Can everybody handle port numbers as part of the URL > specification for the SAML-related endpoints (the inter-site > transfer URL, the responder, and the receiver)? We can, and > we normally use non-standard port numbers for them to keep > them out of the way. It's not a problem for us to reconfigure > to use the usual HTTP ports, though it will make our setup a > little messier. > > > 1.3 Portal > > From about halfway through this section: > > > The <NameIdentifier> element in the AuthenticationStatement > will used > > with the format "#emailAddress" with attribute NameQualifier set to > > the vendors name (e.g. "netegrity.com"). In other words, each user > > will be described as joe@address.com, ravi@someaddress.com, > > alice@someaddress.com etc. > > We normally use the LDAP DN for <NameIdentifier>, and it > would be quite a bit of work for us to change. Is anyone not > capable of handling incoming assertions that contain DNs > instead of email addresses? If not, I'd like to remove this > restriction. > > > <SubjectLocality> element is required to be present. > > Again, we don't currently generate this optional element, and > would prefer not to have to implement it for the interop > event. I'd like to remove this restriction. > > > > Rob Philpott's message > http://lists.oasis-open.org/archives/saml-dev/200205/msg00006. > html contains proposed added text immediately after the text > I commented on above, starting with the sentences "The demo > will rely on identity federation based on email address. > That is, each Authentication Authority will need user > accounts for the users listed below." > > I don't agree with the direction taken in this section. SAML > subjects are explicitly scoped by the <NameIdentifier> > NameQualifier XML attribute. Since each Portal is going to be > authenticating users out of their own user store, and > generating SAML assertions where the subject <NameIdentifier> > is qualified to be coming from their own name space, it would > be a SERIOUS error for any application to ignore the > NameQualifier and treat the subjects as the same just because > they contain the same email address. > > And I'm not just saying this because we don't support email > addresses in name specifiers. This is a key concept in > deploying SAML: the <NameIdentifier> is really only > meaningful in the context of the issuer; if a receiver wants > to keep local state about that Subject, such as additional > personalization information, it MUST store that data keyed by > the fully qualified <NameIdentifier>. > > All ranting aside, if the intent is to demonstrate a system > where more than one portal is able to authenticate the same > "real" Subject, using whatever credentials are appropriate to > that portal, then the correct way to represent this in SAML > is for all of those portals to create assertions with > identical NameQualifier attributes. > > The current plan has each Portal qualifying its Subjects with > the DNS domain name of the vendor, which implies that the > user community that logs into each portal MUST be treated as distinct. > > - irving - > > > -------------------------------------------------------------- > --------------------------------------------------- > The information contained in this message is confidential and > is intended for the addressee(s) only. If you have received > this message in error or there are any problems please notify > the originator immediately. The > unauthorised use, disclosure, copying or alteration of this > message is > strictly forbidden. Baltimore Technologies plc will not be > liable for direct, special, indirect or consequential damages > arising from alteration of the contents of this message by a > third party or as a result of any virus being > passed on. > > This footnote confirms that this email message has been swept > for Content Security threats, including computer viruses. > http://www.baltimore.com This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC