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 , ,
> > 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:]
> Sent: Tuesday, May 14, 2002 5:15 PM
> To: 'Philpott, Robert'; 'Mishra, Prateek';
>
> 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 , ,
> > 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>
