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: [saml-dev] RE: 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.

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

Fine, I don't see an issue here. This is a completely elective element. 

>>Rob Philpott's message
>>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 
>>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.
>>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