OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

 

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

 

 

 

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]