Re: Single sign on in multiple WOApps / passing parameters between apps
Re: Single sign on in multiple WOApps / passing parameters between apps
- Subject: Re: Single sign on in multiple WOApps / passing parameters between apps
- From: Andrew Satori <email@hidden>
- Date: Tue, 6 Mar 2007 16:30:01 -0500
This is one of the nastier issues that faces web developers, not just
WebObjects, but all of the toolkits. There are some common
approaches, but in general they all have some sort of security
ramifications. The issue is that no matter what method you employ,
in order to maintain context across disparate applications (and in
some case the same application across a stateless cluster) requires
that the context information be stored on the client, meaning a Cookie.
Recognizing that a Cookie is intrinsically insecure, that means you
have to deal with those ramifications as a part of the design. Now,
that said, you could use the webserver itself to provide security, so
that a single server hosting several apps could do single point
authentication (which the web browser handles and then stores locally
in it's own state management). Windows only shops use this model
quite a bit to use built-in security against an enterprise Active
Directory tree and they can do so more or less for free. There are
problem with it. Depending upon the configuration, this approach can
lock out non-Windows browsers, and can also lock out Windows machines
that are not members of the AD tree. You can accomplish the same
thing with prudent configuration of OpenDirectory and Apache. I
wouldn't recommend it though. It makes deployment a bit of a PITA
among other issues.
Alright, so we've covered what I would I wouldn't do. How would I
solve the problem? I've done it several ways, each have 'quirks',
but the solution I found that scaled and worked the best used the
databse auth just like you have now. Though I did the implementation
in C# and ASP.NET, the principal design would work in the WO world as
well.
First, I created a single private web service that was used to
validate a client context to an authorized session. When the user
arrived at any of the shared applications, the application performed
a check for a context id in the browsers cookies for the domain. If
it wasn't found, displayed the login display. If it was found, but
there was no corresponding local session, it hit the web service to
validate the context id, and reconstitute a local session from the
web service (refreshing the session expiration in the process). If
the local session does exist, there is no need to display the login,
but there is still a hit to the webserver to refresh the session in
order to prevent it from expiring in the shared database of sessions.
The weakness is of course that context. I've seen alot of web
developers dump user id's, login & password combo's etc into the
cookie. Every time I see this, I want to go crawl in a corner and
cry. In the solution above, I stored a generated context id that was
a server generated guid session id generated by the authentication
web service. That guid would be commited the session database, with
all of the relevant login information stored server side. The only
thing stored at the browser/cookie level is an encrypted guid, that
has a shelf life of the default session length (I elected to use 10
minute sessions, renewing them with each subsequent page view).
A couple of notes though. For a reasonably low volume site, this is
over engineered. Part of the reasons for the designs are that
several of the applications in my case where load balanced across
several servers and data centers. The reason I've continued to use
this design is that it does scale relatively well, but retains a
simple enough deployment model that new junior developers can easily
integrate into it, knowing that with a couple of well documented
calls to a common object, they get a fully constituted session with a
well defined data set.
I am just beginning to rebuild this in WO (or more specifically a
single Java library) so that I can easily implement the same design
in WO, only this time without the latency challenged web service and
going direct to the DB from the Java library.
Andy
On Mar 6, 2007, at 2:30 PM, Pierre Bernard wrote:
Hi!
About a year ago I worked on a single sign-on system.
Unfortunately, I didn't have the opportunity to complete it. I
still have hopes to complete it.
The basic principles are astonishingly simple:
There is one application that handles authentication.
When a user hits the entry page of another application, he gets a
temporary redirection to the authentication application. An ID
(e.g. base URL) of the originating application is passed in the
URL. We also pass the ID of the freshly created WOSession.
The user logs into the authentication application, creating an
authenticated WO session. The user gets a standard cookie with the
session's ID.
Behind the scenes the authentication contacts the target
application notifying the session of the user's credentials. This
can be hack proofed by accepting such communications only from
localhost. Additionally the credentials could be signed.
The page returned after login sets a standard cookie with the ID of
the WOSession in the authentication application and then redirects
back to the target application - right into the authenticated session.
Now the user hits the entry page of another application. Again he
is redirected to the authentication application.
Now the cookie is read, the session restored and the login for is
bypassed. The authentication immediately contacts the target
application and then sends the redirection page.
Best,
Pierre Bernard
Houdah Software s.à r.l.
On Mar 6, 2007, at 7:09 PM, Ken Tabb wrote:
Hi folks,
I think I must be missing something head-slappingly obvious.
I have multiple WO apps, all running off the same user database,
and for each app, the user authenticates against that user
database before they're let into the app (i.e. the Main component
has a conditional login form / page contents, depending on whether
the user has already logged into that app).
At the moment, when app1 sends a user to app2's URL, they are
presented with another login form, which they then dutifully fill
in even though it's using the same username/passwd combination
they used for app1.
Is it possible for app1 to take a logged in user to app2's default
URL, and pass a parameter to the instance of app2 that's dealing
with this request, along the lines of
app2.setLoggedInUser(loggedInUser());
The other route would be to have 1 monolithic "in house app" that
does everything, but I'd be rebuilding that every couple of hours
due to various parts being updated, so I'd rather keep things
modular (several little apps) if possible.
Let me know if this needs clarifying, and thanks in advance for
any help,
Ken
- - - - - - - - - -
Dr. Ken Tabb
Mac & UNIX Developer - Health & Human Sciences
Machine Vision & Neural Network researcher - School of Computer
Science
University of Hertfordshire, UK
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
- - -
Houdah Software s. à r. l.
http://www.houdah.com
- Quality Mac OS X software
- Premium WebObjects consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40druware.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden