[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] AI 66: SSO Profile Enhancements
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]