RE: [security-services] AI 66: SSO Profile Enhancements

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

A couple of notes:

Be careful to distinguish the bindings in ID-FF relating to the AuthnRequest
from the delivery of the Assertion (either via artifact or AuthnResponse).
They can be mixed and matched, and GET and POST are also permitted fairly
fully in all cases.

So I can POST an AuthnRequest and get back an artifact via GET, or I can
URL-encode an AuthnRequest and get back a POSTed AuthnResponse or a POSTed
artifact. And so on. I think that's fine, it gives people more flexibility
in deployment, and the implementation cost is minimal.

The Liberty artifact profile is not significantly different from the SAML
artifact profile. It even delivers the assertion via SOAP in a standard
samlp:Response, and not a lib:AuthnResponse, which is kind of weird in some
ways. The only real change is the allowed POST of the artifact to the SP.

The Liberty POST profile is very different in key ways. There are some valid
reasons for that due to a higher expectation in Liberty that the SSO
assertion should be signed, and not just the AuthnResponse. So key security
measures are placed inside the assertion, and not in the Response, so that
only one signature is needed. Performance vs. elegance, you might say.

As we think about use of SSO assertions in subsequent workflows, we may need
to think about this issue. Many deployers are likely to balk at needing two
signatures.

Structurally speaking across all the ID-FF work, I'm still debating with
myself about whether I think extending RequestAbstractType to do new
protocol messages is the right model. I think we have a big inconsistency
with the Query being inside the request in the old cases, and these new
messages being extensions now. I'm just not sure it makes any difference in
the end, though.

I'm not a big fan of SAML including a protocol wrapper to begin with anyway,
so that's probably the underlying issue for me.

Lastly, I'm already on record about the URL-encoding "rules" for XML in
ID-FF. They prove difficult to accommodate. I'm still wondering why an
artifact-like pull model for the request with a GET to the IdP followed by a
back-channel SOAP request isn't an option. If it's useful in the response
flow, it's just as useful here. It seems like something that can at least
address some of the problem. Maybe then the URL-based encoding can be
reserved for a small subset of request functionality.

-- Scott