RE: [security-services] 2.x suggestions

[Hal Lockhart <hal.lockhart@oracle.com>]

In general we are in favor of this work in essentially the form you have outlined.

We have a specific interest in a lightweight post-based SSO Profile which we are willing to pursue as a part of this work or separately.

I don't see anything here we can't live with, but our priorities are somewhat different.

More comments inline.

> -----Original Message-----
> From: Cantor, Scott [mailto:cantor.2@osu.edu]
> Sent: Tuesday, March 20, 2012 9:42 PM
> To: SAML
> Subject: [security-services] 2.x suggestions
> 
> I had an action to propose some concrete changes to the conformance
> document in the event that a new version of the standard is undertaken.
> 
> As a related point, I thought it would be useful to propose some
> specific extensions that I think ought to be merged into the core
> documents, probably without actually changing any namespaces, just as a
> way of combining and streamlining the material.
> 
> On that subject,
> 
> Core:
> http://wiki.oasis-open.org/security/SAML2DelegationCondition
> http://wiki.oasis-open.org/security/SAML2AttributeExt
> 
> Bindings:
> http://wiki.oasis-open.org/security/SimpleSignBinding

> Possibly some additional work in this area for REST usage, and HTML5
> enhancements?

I am not clear whether "this area" refers to Simple Sign specifically or all the above. What HTML 5 enhancements are relevant here as well as what you have in mind for REST usage, other than the request mentioned in the next paragraph. 

> I think we need to codify IdP-initiated SSO by proposing a basic,
> unsigned, query-string parameter based subset of AuthnRequest
> functionality as a trigger for the IdP. There really is no such thing
> as IdP-initiated SSO, so there has to be a request. Not specifying one
> is non-interoperable.

We are not sure if we have the same idea as you about what constitutes the (non-existent) IDP-initiated SSO flow or what exactly this new request would be used for.

Assuming we are talking about a flow where the SP receives an unsolicited response containing an assertion within an application request, we have concerns about the ability of an attacker to present another party's identity along with an arbitrary request.

Another concern is whether the handshakes can be handled securely without maintaining state in the SP. If cookies are used, can we deal with the cross domain restrictions enforced by user agents?

> 
> Profiles:
> http://wiki.oasis-open.org/security/RequestInitProtProf
> http://wiki.oasis-open.org/security/IdpDiscoSvcProtonProfile
> http://wiki.oasis-open.org/security/SstcSaml2AttributeX500Profile (this
> was really errata to the original)
> 
> Metadata:
> http://wiki.oasis-open.org/security/SAML2MetadataAttr
> http://wiki.oasis-open.org/security/SAML2MetadataIOP
> http://wiki.oasis-open.org/security/SAML2MetadataAlgSupport
> http://wiki.oasis-open.org/security/SAML2MetadataUI
> http://wiki.oasis-open.org/security/SAML2MetadataDRI
> 
> In terms of conformance, I would take a hard look at everything that's
> currently MTI and probably reduce the number of bindings that are MTI
> for Web SSO.
> 
> I could see continuing to have conformance modes that divide into
> "light"
> and "full", but I would change the emphasis between them to have less
> to do with "state management" and more on which pieces of the spec I
> see get used heavily and are useful for truly scalable deployment. A
> "full"
> implementation shouldn't have to do things like logout or NameID mgmt,
> but should have to support metadata for configuration and at least one
> full metadata profile that is interoperably specified.

We understand the need for autoconfiguration based on metadata, but see a need to define a limited set of specific features which are MTI.

> 
> I think if we're going to make logout part of any mandatory conformance
> class, we need more specified on how it's supposed to work and a
> practical set of UI guidelines for it. Since I don't think that's
> doable, I don't happen to think it should be mandatory, but I'm open to
> somebody supplying the missing material.

We don't think it is possible to force implementations to support a logout process which has the properties Enterprise customers want (e.g. provide a basis for enforcing single login per id at any given time) therefore we have no interest in making logout MTI.

> 
> Finally, I would tighten and clarify conformance for implementing ECP.
> We have growing interest in that material, and while I don't think it
> should be MTI, it should be more interoperable by requiring some
> specific client/IdP interactions.

ECP is not a priority for us and we certainly don't want it to be MTI.


Hal

> 
> That's a start anyway.
> 
> -- Scott
> 
> PS. Might also be worth looking at deprecating some things that see
> little or no usage or were intended to be replaced by other work.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-services-unsubscribe@lists.oasis-
> open.org
> For additional commands, e-mail: security-services-help@lists.oasis-
> open.org
>