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

["Scott Cantor" <cantor.2@osu.edu>]

> [Phil] Your first point makes sense. I think this case starts to deal
> with the natural eb and flow as users begin to make choices and as
> enterprises decide to push old fashioned "LDAP" accounts into the
> federation world. In this large use case, the IDP and SP may be in the
> same vertical but they have no formal relationship --> this is why
> they want federation. :-)

I don't think the relationship really pertains beyond the technical issues;
it's a question of who knows what, when, and what you can do with that
information.

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

> [Phil] This is what I thought. It's leading me to believe that
> provisioning will have to be accomplished in a more brute force
> approach --> where something like an ManageSubjectRequest (a potential
> new operation) is handed to the IDP by the SP.

I thought SPML was meant for the kind of provisioning you're talking about.
 
> The IDP is free to
> accept/reject/map the request without having to reveal the original
> status of the user.

I don't see how an IdP would know to do anything with it unless the
identifier were already known to be shared, and in that case, it is just
SP-initiated NameID mgmt.

> [Phil] That helps a lot. There seems to be a lot of confusion about
> this. Apparently it is being used for temporary identifiers. Might be
> something for the TC to consider clarifying?

I think the errata is pretty clear about it.
 
> [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.
 
> [Phil] Thanks, those comments help a lot. It seems to me that the
> choices really are:
> 
> 1. SP does bulk provisioning in an offline/backchannel
> 2. Invoke some other protocol or SAML extension (e.g.
> ManageSubjectRequest proposed earlier) to enable dynamic provisioning.

I continue to struggle to understand how this proposal makes sense, or
solves anything related to the problem you're talking about. I definitely
need a more concrete example.

On the phone, you or somebody else drew an analogy to LDAP and using a
client to add an entry to the LDAP directory. That's all fine, except that
doing that usually involves setting a password (provisioning the
credentials, not just the entry). I don't see how the analogy holds.

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.
 
-- Scott