tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject FEEDBACK On SSO (Single Sign On) across domains
Date Tue, 24 Apr 2007 11:24:01 GMT
Copied to User Group

Hi Jeremy,


== ORIGINAL PROBLEM ==
Tomcat cant do SSO across domains like this  <ANYTHING>.MyCo.com

Research revealed several opensource java frameworks,  namely

= OPENSSO is a SUN release but it doesnt seem to have a great following...

= JOSSO is an open source project maybe for you.... I felt it overdoses on XML and its also
based on valves.

= CAS... if you want to do SSO for a whole company.... I like it, used by many universities.
http://www-128.ibm.com/developerworks/web/library/wa-singlesign/


= SimpleSSO
I found SimpleSSO, which is what I think the original user was looking for... think its part
of spring framework, but article shows you how to use in tomcat.
Its very much like Tomcats SSO valve, but caters for <ANYTHING>.MyCo.com domains....
(ATTENTION JEREMY)
http://docs.codehaus.org/display/SSSO/SimpleSSO+Installation+Guide#SimpleSSOInstallationGuide-tc55

And I'm busy making a little authentication filter called GangBang... the idea is one can
develop on single tomcats, and then group "dispersed" tomcats into a SSO across domains. 
The prototype will only support BASIC, DIGEST, and Tomcat user-config realm (the user xml
file).
It will feel very much like Tomcats built in security, but it wont use it...

Now you may be asking why dont I integrate with Tomcats security, like for example SimpleSSO
or JOSSO have done.
The reason is that it is impossible to intercept Tomcats security in a Filter.  
The authentication and security related cookies happen at the "boundaries" of the filter.
So no matter what you do in a filter... tomcat will authenticate before it gets to you, and
do its thing "after" you. You cant control authentication in a filter.

Now thats unfortunate because Filters are standard portable things... and that leaves Valves,
or you abandon Tomcats security (what I'm doing).
Valves are kinda like filters but they allow you to get at and override Tomcats internals...
thats what these other guys are doing... BUT they NOT standard.
Now if the Tomcat developers are supplying the valves, you can be certain they will move across
versions, but as soon as a third party makes a valve, then you should know, that if they dont
upgrade it, it probably (very likely) will NOT work on the next version of tomcat.

I checked tomcat 5.5.17, 5.5.23 and 6.0 and that Valve infrastructure is changing allot...
its not possible to write one valve for all those versions.
So I think VALVES are power filters only for Tomcat staff... its a clever concept, but its
not portable.
--- What I'm trying to warn against is that if you use a third party valve... better research
the likelihood of the supplier upgrading it ---

OK and to end I just want to mention the mechanism at work in SSO...

>From the server side they talk about tokens and tickets and blah blah... but its easier
to think of it from the browser side, because its actually a very simple mechanism at work
in the browser and thats really all servers have to work with.

When a browser is challenged... then for the "domain and realm" (realm is just the name of
the challenge), it sends the encoded username and password.
 It either gets it by prompting you, or if it does have it already, it just sends it again...
if challenged.
 MS IE seems to send it in every request, but some browsers only send on a challenge, which
I think is actually how the RFC outlines it.

When the domain changes, then even if the challenge is for the same realm (eg Admin Login),
the browser will not return the encoded info.
However cookies DO have the ability to move across domain names.... if a cookie is set with
the domain (.MyCo.co) say on HQ.MyCo.Com... then the browser will respond to NewYork.MyCo.Com
as well as (<ANYTHING>.MyCo.Com) with the cookie.

So cookies can bridge when normal authentication refuses... and so the server just has to
be able to remember the cookie it set, for the user. 
Cookies become tickets and tokens in servers, and users get wrapped up into roles.... etc
etc.

Hope that answers the question.....

regards,
Johnny

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message