Re: [security-services] Blog post on Change Notify / comments on Aug 24 meeting

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

Scott,

Thanks for the comments. I've added your edits. For the questions/discussion items, see below.

On next week's call, I would like to sort out the synchronous/front-channel use case for NSN. I believe most of it is covered in the existing Web SSO profile. 

Once we have this confirmed, we can target what the add operation is intended to accomplish in synchronous mode over and above the web sso profile.  As Scott says, it may not be needed. I think the only difference is subtle.  The Notify Issuer is indicating to the Notify Target that the issuer believe this to be a newSubject. Where as in reality only the target knows the actual state.  This has subtle impacts on the surrounding workflows that the issuer and target may have.  The issue I believe is mediating state without require control of state.

After discussion next week, I will complete draft 02 and post.  For this week, lets keep comments based on draft 01.

Phil
phil.hunt@oracle.com




On 2010-08-27, at 10:12 AM, Scott Cantor wrote:

> Some general comments on sstc-saml2-notify-protocol-01b, ignoring some of
> the basic editorial issues, incorrect hyperlinks, etc. If you could, please
> try and go through the document and clean up the formatting of any XML
> element names using the Courier font, so we don't have to do this later in
> an editorial pass.
> 
> Also, you need to define the XML namespace here, add it to the table in sec
> 1.1, add samlp to that set, and properly qualify the elements in the text.
> 
> Line numbers are from PDF.
> 
> There are lot of references to the earlier proposals. I suggest removing
> them and making this a stand alone proposal, and if you want the back
> references, use a change log appendix at the end for that.
> 
> Sec 1.2, I suggest qualifying these terms as "notification issuer and
> target" to avoid collision with existing notion of Issuer in SAML. Also
> rephrase SAML service entity to SAML entity.
> 
> Sec 1.3/1.4, seems like a lot of these references are unneeded, such as
> 5280, 3820 and the XML security specs. Also the reference to delegation
> conditions is pointing to a CD instead of the CS.
> 
> Line 212, I would change multi-protocol to "protocol agnostic". We're not
> saying you have to use more than one.
> 
> Line 214, suggest wording as "In typical SAML scenarios, user information is
> propagated through the use of the Browser SSO Profile [SAML2Prof] and
> similar profile variants..." Also suggest softening the sentence with "there
> is no means..." to point out that the IdP can notify the SP of NameID
> changes and either party can notify the other of deprovisioning, but that
> other changes aren't addressed. It seems to be incorrect about what you can
> do, for example saying that an IdP can't inform an SP of defederation, which
> is just wrong. I would avoid words like "core profiles", that's not a
> defined concept.
> 
> I would also avoid terms like "web service providers", that's just too vague
> and suggests notions of SOAP and such, or assumes HTTP is the application
> protocol, which SAML does not assume. I think you just mean service
> providers.
> 
> Lines 243-244, this is already by definition in SAML, doesn't need to stated
> here.
> 
> Line 250, I think you want to relax this to "any supported profile of the
> Authentication Request protocol", rather than assuming Browser SSO.
> 
> Line 291, s/expires/Expires
> 
> General schema questions, why is ChangeNotifyBaseType necessary? Can the
> message just be defined as one type extension of RequestAbstractType?

I might not have constructed this in the best way, but ChangeNotifyBaseType adds the operations "NewSubject", "ModifySubject", "RetireSubject" to RequestAbstractType.  Then, NewSubjectType and ChangeSubjectType extend ChangeNotifyBaseType to add elements/attributes needed for those operations. The retireSubject operation currently has no parameters...though we may change that.
> 
> Also, should the *Subject elements carry a Subject or a
> NameID/EncryptedID/BaseID choice directly? Subject implies an optional
> choice of those elements plus optional SubjectConfirmation. So if the
> SubjectConfirmation isn't involved (which seems likely here), all you should
> need is the identifier, not a full Subject.
Agreed, this makes sense.  There may also be a terminology issue. For example, in the "NewSubject" operation, it does not necessarily mean a Subject is contained. It  currently contains just a set of attributes that collectively represent an entity that will likely become a Subject in the target.

Is it better to use "NewEntity"/"ChangeSubject"/"RetireEntity"?
> 
> Sec 2.6, I think this answers my ChangeNotifyBaseType question...you have
> this response message layered on RequestAbstractType. Just pull the base
> type, and base the request and response messages directly on the proper SAML
> types.

Not sure I understand. I thought that is what I was doing. Maybe you mean to eliminate the base type and have each message type go directly on RequestAbtractType? I guess I was thinking that makes the schema more repetative.
> 
> Sec 2.7, I suggest swapping this with 2.8, the examples should be at the
> end.
> 
> Sec 2.7.1, I suggest replacing Tom Scavo's UIUC identity, since he's not
> with UIUC anymore. Just use a dummy identity. Also, I think your OID for
> mail is off, but I must confess that it's probably a matter of opinion,
> sadly. FWIW, the one we use in eduPerson is 0.9.2342.19200300.100.1.3
> 
> Line 461, it says "the default falls to the Issuer node". I can't parse
> that, but even so, it then says the target does the initiating, so that text
> seems off.
> 
> Sec 2.8:
> 
> I think you need to separate any of this front vs back channel discussion to
> a formal protocol profile (which you need anyway). The base protocol rules
> should be presented in a binding agnostic fashion, and then you can have a
> profile section that has normative language based on the binding. The SAML
> profiles doc uses the terms synchronous and asynchronous in place of back
> and front. I see section 4, but that seems to be about profiles of existing
> profiles in conjunction with this new one, not just a profile of the new
> protocol. I think you want a cleaner separation of the rules here.

Agreed.  I think this is currently the major priority in the document. I want to sort out how it should work with everyone, and then we'll clean up the separation issues as you describe.
> 
> Line 499, why is LDAP issuer initiated only? Couldn't the issuer have an
> LDAP for the target to query?

True.  Issuer would initiate with an add/modify/delete, while the target could use an ldapsearch.

There is another issue here about protocol subject identifiers that I will open as an issue in another thread.
> 
> Line 511, it sounds like you want actionAfter to be omitted, so just say
> MUST NOT include it.
> 
> Sec 4.1: Ok, I really just don't understand the point of this. What does
> adding this round trip achieve? Why wouldn't you just do SSO like now? I'm
> missing something obvious...
> 
> To the extent that it's needed, I think you want to avoid duplicating all
> this SSO profile material here. You should just compose it by saying "the
> protocol exchange is followed by the use of any profile of the SAML
> Authentication Request protocol...".
> 
>> As for yesterday's TC call, my apologies for arriving just as the call
>> ended. I agree with Thinh. We need to review section 2.7.2.  Can the
> normal
>> web sso profile handle the requirement mentioned in the front-channel
>> example?
> 
> I think I need more help with the use case the example is trying to address
> to answer that. As it's described in the fuzzy diagram, I just don't get it.
> This isn't how federation normally works. You don't decide what to call the
> user at the SP by asking the SP, you just assign an identifier, supply it
> via SSO and the SP links that to its own ID if it wants to. Why would you
> *not* just do this? What's the use case?

Agreed. I think we need to get clarification from NSN on this aspect.
> 
>> 1. Initial negotiation of identifiers - per the NSN requirements
> 
> I'm still trying to understand them.
> 
>> 2. Triggering a specific set of attributes to be transferred the first
> time
>> a user federates. Example, the IDP believes this to be potentially the
> first
>> time the user has accessed the relying party and is indicating a potential
>> "new user".
> 
> Ok. It knows that independently of this new protocol proposal, so...
> 
>> There are cases where the attribute flow for first time
>> federation is different than normal SSO attribute flow. [btw. the fact
> that
>> the attribute flow changes during initial sign on isn't necessarily an
>> optimal approach in my opinion, I just note that the use case has been
>> arising]
> 
> That's fine, but I don't see how it relates to all this work.

This is coming up because some use cases want different things to happen on an initial federation event vs. a typical SSO profile.  Hence, ChangeNotify can help with the "NewUser" notification.  In practical terms, the notifier is just saying to the RP, I believe you haven't met "Scott Cantor" before, here are his attributes. Of course, it is always the case that the RP and the user may be very familiar with one another.

In the enterprise cases, we are seeing a need for many more attributes to flow on initial contact.  E.g. the first time an employee touches a cloud service provider, a bunch of provisioning events fire off at the RP.  On subsequent SSO events, only basic identity and role attributes are transferred.  Of course, one could argue that the SAML assertion should contain all attributes every time, but that turns out not to be practical or scalable. I am told there are folks with 100s of attributes to provision on first contact vs. < 10 or even 2 or 3 on subsequent logins.
> 
> -- 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 
>