OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[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