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

[Phil Hunt <phil.hunt@oracle.com>]

Provisioning of claims seems to be a natural part of the life-cycle  
between SPs and IDPs. After-all, SPs also generate claims themselves.

That said, I agree, provisioning probably isn't a big issue right now  
if your use case focuses on SSO and can use bulk provisioning within a  
tight vertical.

I agree, SPML could potentially work fine if agreed on an profiled in  
the context of SAML. Without that, the real issue is too many choices  
and no agreement in advance on standards.

SAML also has a different way of handling identifiers.  Would SPML be  
compatible with SAML use cases?

I wonder what other differences come up as SAML use cases tend to be  
dynamic, single-entity rather than bulk provisioning cases.

Phil
phil.hunt@oracle.com




On 29-Apr-10, at 12:36 PM, Scott Cantor wrote:

>> [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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>