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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] Question on SP initiated authentication & provisioning first time user


After setting out the use case I have in mind, more comments are inline.

I know a use case where the IDP knows the user under his own unique
identifier. The SP, independently, also knows the user. At this point in
time the user would like to take advantage of the SSO provided by the
IDP and cause the SP rely (for his account) on the IDP. This is not the
bulk-provisioning that can be done efficiently offline, but a case by
case bases, where likely more IDPs with their user accounts are
involved.

In that scenario the SP  

-----Original Message-----
From: ext Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Thursday, April 29, 2010 9:37 PM
Subject: RE: [security-services] Question on SP initiated authentication
& provisioning first time user

> [Phil] I think this is up in the air. The thinking is that the SP may
> maintain or generate a new SP NameID since it already knows the user.
> It is quite reasonable that the SP NameID would be unique to the
> target IDP.

What SAML allows is for an SP with an existing shared identifier with an
IdP
to ask the IdP to attach an alias to it. It doesn't allow you to propose
attaching that identifier during SSO. Using the Subject there doesn't
mean
the same thing, it's for specifying which user you want authenticated
when
there's *already* a shared identifier.

[Joerg]does your statement imply, that if SP1 knows the user as Jim and
SP2 knows the user as j.owl it is not possible for SP1 and SP2 to share
an IDP, because at the Auth_Request both would not share the same
NameIdentifier ? I hope I am wrong.




 
> [Phil] Correct. Ideally the user already has an account with the IDP,
> otherwise why choose it. I think the problem is to have enough
> signaling so that the UI can act gracefully. However as discussed,
> security reasons seem to block sufficient signaling.

Yes, I agree. But I don't think sending more data from the SP to the IdP
changes anything.

[Joerg] If the IDP wants to know which NameIdentifier or Alias the user
has at the SP, there needs to be a way to find out. Why would that not
change something ?


 
An IdP that received such a request can't do anything with it, because
there's no way to bind it to the identity of somebody that later shows
up.
And if you're doing it front-channel with an indexical reference to the
client, that is simply SSO and needs no additional protocol; the IdP and
SP
are reversing roles. Simple to describe, at least.

[Joerg] Interesting enough, I see the reverse of the roles also as a
necessarity, with the big addition, that I would not want to force every
SP to implement the full IDP protocols. I would like to have a simple
IDP initiated way to query the NameIdentifier from the SP. The best
place NSN sees this to be after an auth_request, that was done prior any
setup. Then the IDP uses a NameIdentifier request as part of an error
code. This initiates a account binding and also finishes the
auth-request with the user being logged in at the SP. Additional
advantage is that the SP does not need to know about the accounts at the
IDP, because the IDP will send or not send a NameIDRequest. 

Hope this clarifies and satisfies both Phil's and our needs.

Kind regards
Joerg



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]