Re: [security-services] 2.x suggestions

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

On 4/23/12 11:22 AM, "Hal Lockhart" <hal.lockhart@oracle.com> wrote:
>
>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.

As I noted privately, Kantara is engaged in a process to take over and
possibly advocate for a somewhat-simplified deployment profile called
saml2int.

http://kantarainitiative.org/confluence/display/fiwg/saml2int

I've done implementation profiles that cover the same ground (those would
be the direct analogies to what SAML defines in its profile document).

It will certainly, at this stage, be more extensive than you're seeking,
but convergence in this would be a hugely advantageous thing, particularly
if it resulted in Java reference code.

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

SimpleSign. I meant that I know there's some work going on in OpenID
around using HTML5 features to do certain things that traditional
redirects and POSTs don't do. I'm not familiar enough to know what those
things are. I believe some of it is designed to obviate problems with
third party cookie usage where logout is concerned.

In terms of REST, my point was that obviously that's a set of requirements
that tends to disapprove of anything involving XML Signature.

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

I've been having an extensive discussion about this on the Kantara FIWG
list. I would claim that this is a property of IdP-initiated SSO period.
And SAML currently requires that feature. I think this needs to be looked
at.

All I was saying was, claiming that IdP-initiated SSO is somehow mandatory
but providing no standard on-the-wire trigger for it is non-interoperable.
Its very nature assumes that the threat you speak of is a given, AFAIC.
That's worthy of discussion, but short of outlawing it, I don't see what
the answer is.

>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?

By definition, there can be no advance state in the SP if SSO is
IdP-initiated.

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

At minimum, there would be a need to look at what each MTI profile
requires in the area of autoconfig, as a way to scope that. I would also
like to see more explicit language in profiles that just requires metadata
be supported in whatever subset the profile needs, rather than the
somewhat fuzzy language we have now around it in the profiles.

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

I can't say I've gotten a lot of requests for that particular feature. Our
biggest problem has been Firefox, and their refusal to undo the change
that caused SSL session cookies to be maintained across restarts. No other
browser does that, to my knowledge. So that has led to a lot of perfectly
reasonable demands for logout, but we're not comfortable building
solutions that depend on third party cookies. If HTML 5 offers a possible
improvement, that may be worth looking at.

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

I'm not suggesting it be MTI, but rather that implementers of it be
constrained to support more specific things than it currently requires. It
should be more interoperable, independent of whether it's more widely
implemented.

Thanks,
-- Scott