[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [saml-dev] RE: Comments on draft-catalyst-interop-plan-01
Irving, >>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. >> I don't see why this should be a problem. As no objections have been raised I will add ":port_no" to the proposed URLs. >> >>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. >> There may be an issue here. I am not sure our general DN parsing stuff will be integrated and ready by June 17 (rehearsal). Jehan has proposed a compromise: add an attribute with an e-mail address and also generate a name in #X509SubjectName format. Is this acceptable to people? >>> <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. >> Fine, I don't see an issue here. This is a completely elective element. >> >> >>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. >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC