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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: RE: [saml-dev] SSO across heterogeneous clients

Title: RE: [saml-dev] SSO across heterogeneous clients

In response of your summary…


1)      Specifically if we have a web application and a Java swing application both authenticate from the same source (Active Directory)… My definition on single-signon here is that you present you credentials (in this case username/password) ONCE and both applications will have that authentication context and not need to present credentials again. 

2)      I understand that this may be out of scope of the SAML specification as it stands… but this is definitely a real use case and I understand the implementation may not be interoperable. 


Thanks for the response…


-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, May 02, 2002 11:38 AM
To: Quintas, Peter; saml-dev@lists.oasis-open.org
Subject: RE: [saml-dev] SSO across heterogeneous clients



> Can SSO across web and fat clients be accomplished in SAML? 
> There is a
> really nice write-up in the bindings doc on how this can be
> accomplished
> in an all web scenario, but it doesn't touch on that heterogeneous
> client scenario.  Can anyone shed any light on this for me? 

It is not entirely clear what requirements you are trying to meet. Specifically, what do you mean by a fat client?

It seems to me that there are three characteristics of the client which are relevant to this question.

1. Can the client be provided with new software to solve this problem or must we consider its security behavior fixed? Note this is not the same as saying whether or not it will have application software specific to the problem.

The SAML Browser Profiles specifically assume the security behavior of the client is fixed and live within its limitations. If the security behavior can be changed, as is generally assumed in a Web Services environment, many more alternatives become feasible.

2. What kind of Authentication method or methods are available in the environment in question?

The SAML Browser Profiles pretty much assume a password type mechanism for authentication. SSL (with client certificates) and Kerberos can provide single signon (depending on your definition) without any additional mechanisms. Obviously mixed environments are possible, but it is necessary to specify which ones before proposing a solution.

3. What kind of remote access protocol is being used? The term "fat client" suggests that the answer is "not http", but that still leaves a lot of possibilities, e.g. SOAP, RMI, DCOM, CORBA, etc.

I will make a few observations about SAML.

SAML has deliberately avoided defining new Authentication mechanisms. It is however designed to be used in a variety of environments and with various other technologies, including multiple authentication methods.

SAML Profiles are the only means for achieving interoperability. By this I mean either you must use one of the ones defined by the TC or you must go through the process of answering the same kinds of questions and making the answers available to anyone you wish to interoperate with.

Anyone is free to pick and choose elements of SAML, e.g the assertion schema, and use them in any way they choose. However this is a mere side-effect from the perspective of the TC. The reason so much time and effort has been put in on SAML is to achieve interoperability.

SAML Profiles are driven by usecases. The case of SSO for web browsers was identified as an important problem for which no standard solution existed. In spite of what you may have heard, we did not set out to "solve SSO" only to standardize this particular usecase.

So in summary, a) if you could be a little more specific about your usecase, I would be glad to propose some possible solutions, which might or might not use SAML mechanisms and b) even if you were to implement one of my suggestions, you would not achieve interoperability unless others implement the same thing.


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

Powered by eList eXpress LLC