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:] 

Sent: Thursday, May 02, 2002 11:38
AM

To: Quintas, Peter;


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.

Hal