[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AI 66: SSO Profile Enhancements
My task here is to compare the "Destination-Site First"
flows as found in [1], versus those found In ID-FF 1.1. The latter materials may be found
in Section 3.2 of [2] with detailed "profile" realizations in
Section 3.2 of [3]. I conclude
with some recommendations and open questions.
The ID-FF flows are pretty
extensive. Here is a summary from [2] Prompt the
Principal for credentials if the Principal is not presently authenticated. Prompt the
Principal for credentials, even if the Principal is presently authenticated. ____ Federate the
Principal's identity at the identity provider with the Principal's
identity at the service provider. __ _ Issue an anonymous
and temporary identifier for the Principal to the service provider. ___ Use a specific
protocol profile in responding to the request. ____ Use a specific
authentication context (for example, smartcard-based authentication vs.
username/password- ____ based authentication). ____ Restrict or limit
the identity provider's ability to proxy the authentication request to
additional identity providers. ____ Additionally, the
service provider MAY include any desired state information in the request that
the identity provider ____ should relay back to the service provider in
the response. ____ In addition the <samlp:RequestAbstractType> from which <lib:AuthNRequest> is derived always carries a unique RequestID,
Version information and time instant. I do not see any additional need for additional context
information.
(a) As far as the POST profile goes,
both follow expected lines and seem quite comparable. (b) The main differences lie in the
artifact profile. In [3], the artifact profile is based on a technique given in In
[1], the mapping into a query string is carried out by "hand" and a
specific query string with certain name-value pairs described. So the question
goes to Liberty ID-FF implementers: what is your experience using URL-encoding
technique in Section 3.1.2? Do you recommend we stick with it in SAML 2.0? References: [1] sstc-bindings-extension-03 (can be found in the document
repository under SAML 2.0) [2] [3] Version 1.1 3 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]