[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]