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.

 

 
Do the
     flows in ID-FF 1.1 convey adequate contextual and other data from Service
     Provider to the Identity Provider?

 

 

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.

 

 

 

 
Comparison
     of profile realizations in [1] and Section 3.2 of [3]

 

(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 

Section 3.1.2. The main idea here is take the contents of an XML element
and use URL encoding together with some rules to map it to a linear string,
which can then be included in the query portion of a URL. Some size
restrictions on portions of the XML element are also proposed (URL's and
relay state components should not be larger than 80 bytes each).

        In
[1], the mapping into a query string is carried out by "hand" and a
specific query string with certain name-value pairs described. 

        
I find it difficult to definitively compare these two techniques. Clearly
the technique in [1] 
"works" as it is put together by hand. On the other
hand Section 3.1.2 describes a more general technique.  The real question comes down to whether
it is effective in practice. 

 

 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] Liberty Protocols and
Schema Specification, Version 1.1 3

15 January 2003 4

 

 

[3] Liberty Bindings and
Profiles Specification 2

Version 1.1 3