[saml-dev] Comments on draft-catalyst-interop-plan-01

[Irving Reid <Irving.Reid@baltimore.com>]

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.