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] Forwarding thread on "previously established an identifier usable by the requester"?


Sorry for taking so long to respond to this.  Comments are inline below.
Apologies for the thoughts being a bit disorganized.  

> "This protocol MUST NOT be used in conjunction with the
> urn:oasis:names:tc:SAML:2.0:nameidformat:transient <NameID> Format."

That certainly clarifies that particular issue. 

> Some general NIM notes...
> 
> Brian correctly notes that even if you start with a global database of
> X.500
> names, supporting IdP or IdP Extended mode means you support NIM. That
> means
> your implementation MUST accommodate the SPProvidedID construct
regardless
> of format (excluding transient, as noted above). That of course means
per-
> SP
> state, no argument from me. That's why the light modes were adopted,
in
> which NIM is not supported.

I can sort of see where this is going but the implications are not
clear.  Some questions jump to mind:

Does being an IDP basic or extended imply that you must keep per-SP
state about the IDP side of the identifiers too (in order to honor
AllowCreate)?  Maybe keeping state is too strong as there way be ways to
honor AllowCreate w/out actual state but I think I gravitate to
describing it as keeping state because that that's what the external
behavior of the IDP looks like.  
 
Does being a light IDP mean that you must ignore AllowCreate?

Can a light IDP issue identifiers with the 'persistent' format?  If so,
is AllowCreate meaningful in this situation?

Scott discusses the concept of "sender-imposed state" below.  Is the
IDPs support of sender-imposed state dependant on its operational mode?
If so, is operational mode inferred from the available endpoints in
metadata?  If not, what is it based on and how is an SP to know how the
IDP will treat AllowCreate an NIM?

> I note that the language of NIM (I'm picturing talking mice here, free
> SAML
> mousepad to anybody that gets the reference) is really in terms such
that
> my
> question above isn't exactly relevant. If an IdP is planning to switch
> from
> one format to another, the point of NIM is to tell the SP that by
sending
> it
> a message to that effect, and of course in that case, sure, the
> SPProvidedID
> is going to be preserved across formats because it's really "changing"
one
> NameID into the other, not so much using both at the same time.

A little off topic here but I don't see how NIM can be used to change
the format of an identifier - the <NewID> element in a
<ManageNameIDRequest> is of type string.  Seems like all you can do is
change the value.


> Finally, let me add a note about termination (SP initiated in
particular).
> I
> just can't see a reading of this that forces the IdP to do anything,
and
> this is not a change from ID-FF. In fact the text is almost exactly
the
> same
> (and I don't think I wrote that text, even though I edited part of
1.2).
> Nothing in ID-FF says anything normative about the IdP doing anything,
so
> I
> left it the same.
> 
> The problem is, how does that make any sense if AllowCreate is to
matter?
> I
> think it could be argued (I guess Greg did) that we need to strengthen
> that
> text in such a way that it is more directly peered with the use of
> AllowCreate. Not so much in the sense of requring they be used in
tandem,
> but describing the conditions under which they both apply (and by
> implication when they don't).
> 
> So, consider this expansion of lines 2475-2479 based on a concept I'll
> call
> sender-imposed state.
> 
> ---
> 
> "If the <Terminate> element is included in the request, the requesting
> provider is indicating that (in the case of a service provider) it
will no
> longer accept assertions from the identity provider or (in the case of
an
> identity provider) it will no longer issue assertions to the service
> provider about the principal."
> 
> "If the receiving provider is maintaining sender-imposed state
associated
> with the name identifier, such as the value of the identifier itself
(in
> the
> case of a pair-wise identifier), an SPProvidedID value, the sender's
> consent
> to the identifier's creation/use, etc., then the receiver can perform
any
> maintenance with the knowledge that the relationship represented by
the
> name
> identifier has been terminated."
> 
> "Any subsequent operations performed by the receiver on behalf of the
> sender
> regarding the principal (for example, a subsequent <AuthnRequest>)
SHOULD
> be
> carried out in a manner consistent with the absence of any previous
> sender-imposed state."

It sounds like it is still at the IDPs discretion as to if they want to
maintain such sender-imposed state.  It seems a bit of a contradiction
that there are situations where a sender can impose state but cannot
know if the receiver is in fact honoring that state.  Maybe I'm missing
something here - I don't know.

> ---
> 
> Now, cynics should note that this re-assigns the problem to the
definition
> of "sender-imposed state". And that the spec imposes some
(SPProvidedID),
> assumes some that could be addressed in a manner not requiring actual
> state
> (a pair-wise value), and leaves the rest to implementations
> (consent-oriented value-add). Is this better? I don't know.

The wording feels better on first read but I'm not sure it doesn't just
push the problem to a different level.

> Let me try some alternative text and carve out transient in the
process,
> also based on the new text for termination, obviously.
> 
> [SAMLCore]
> 
> Replace definition of AllowCreate, lines 2123-2129:
> 
> "A Boolean value used to indicate whether the requester grants to the
> identity provider, in the course of fulfilling the request, permission
to
> create a new identifier or to associate an existing identifier
> representing
> the principal with the relying party. Defaults to "false" ir not
present
> or
> the entire element is omitted."
> 
> Replace lines 2143-2147 and insert new text at line 2130 (beginning of
the
> explanatory text):
> 
> ---
> 
> "The AllowCreate attribute is used to control the creation of state
> maintained by the identity provider pertaining to the use of a name
> identifier or (or any other persistent, uniquely identifying
attributes)
> by
> a particular relying party, for purposes such as dynamic identifier or
> attribute creation, tracking of consent, subsequent use of the Name
> Identifier Management protocol (see section XX), or other related
> purposes."
> 
> "When "false", the requester constrains the identity provider to only
> issue
> an assertion if such state has already been established or is not
deemed
> applicable to the identifier.

Who decides if it is not deemed applicable to the identifier?  If this
decision isn't normative, then different implementations will have
different interpretations and that can lead to interop problems.  

> Thus, this does not prevent the identity
> provider from assuming such information exists outside the context of
this
> specific request (for example, establishing it in advance for a large
> number of principals).
> A value of "true" permits the identity provider to take any
> related actions it wishes to fulfill the request, subject to any other
> constraints imposed by the request (the IsPassive attribute, for
> example)."
> 
> "The use of the AllowCreate attribute MUST NOT be used and SHOULD be
> ignored
> in conjunction with requests for or assertions issued with name
> identifiers
> of the urn:oasis:names:tc:SAML:2.0:nameid-format:transient Format
(they
> preclude any such state in and of themselves)."
> 
> ---
> 
> Related changes could be made to the profiles doc where the old
> AllowCreate
> text is simply repeated, but I'd just as soon pull it from that
profile or
> refer to core.

If the rules are the same, I think it'd be much better to just pull it
and refer back to core.

> I think this is more explicit, certainly, but I hope it does a better
job
> of
> suggesting what the "trigger" is for looking at AllowCreate, the
creation
> of
> local state. If your implementation provides for no such state in the
mere
> issuance of assertions (dynamic creation of IDs, tracking consent,
...),
> then you're not going to have to impose that constraint.

To me, what is important is what behavior the SP can impose on the IDP
with the attribute.  How is the SP to know if the IDP implementation
provides such state in the mere issuance of assertions?  Is it
completely arbitrary and at the discretion of the IDP?  Is it a function
of name identifier used?  Is it a function of the operational mode
(light or basic/extended)?  Or is it something else?    

All of the ID-FF implementations I've seen used the Liberty equivalent
of the AllowCreate attribute quite explicitly on the SP side.  The SP
would only tell the IDP to allow creation of an identifier if the
principal had authenticated locally at the SP and had not previously
federated his/her identity with that IDP - so the SP knew it was linking
accounts as a result of the SSO.  As far as I could tell it wasn't about
user consent it was about having a little control over the state of
linked user accounts.    

> I also think if that's not sufficient to get the interop people want,
> another profile around getting and tracking principal consent (which
will
> directly trigger all those "ifs and buts" I wrote in above) is needed
and
> is
> better than baking it into the lowest level of the spec or the SSO
> profile.

The spec is about identity so I do think it is appropriate for clear
normative rules about how identity is represented and managed to be at
the lowest levels of the spec.

-Brian


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