|
From: | Mason Ham |
Subject: | [Auth]How the system can work with app.servers |
Date: | Wed, 3 Oct 2001 13:37:14 -0400 |
Basically you set up a proxy (security reasons so
you only have one "load balanced" ip that is using an external http
port).
So with the jpg below I will try and walk through
the way I have used the system.
User has already "auth'd" in.
User -> Bob
LCRS-> Least Common Rule Set.
CBO-> Client Browser Object.
1) Bob signs up with an auth server. List is done
out of band and before he serfs to the Front End Site.
Arrow
J
2) Bob goes to a site that is part of the
federation and asks to see a protected resource.
Arrow
A
3) The system puts up it's LCRS page for itself. In
this example it is user/password.
Arrow
A
4) Bob fills in the information and it is
transmitted back to the app.server.
Arrow
A
5) The app.server creates an clientBrowser object
(CBO). This object is basically a session aware bean.
6) The bean uses the session that the browser has
setup as the session that it will map for this user. It then request an HTTPS
connection with the auth. server. Since the site is behind firewalls, it uses a
proxy to get HTTP/S access.
Arrow
C
7) The proxy then creates a session with the auth.
server for the CBO. This is request had the information for the authentication
in it and is posted to the server. This is an XML/Encrypted/TimeStamped/Hashed
value with a public key of the auth. server. So yes you have to
have server's knowing keys from auth. servers and vice versa. I
didn't say it was perfect :-)
Arrow
D
Anyhow, the data is received and decoded and
checked against the record that the user created. At this point the LCRS
for the auth.server/user/service is checked and calculated, it turns out that
the user wanted to have level2 as the min. set of auth. so the server returns a
positive code for the info. received but also a request for more and the meta
data that is needed, ie the three random questions to ask the user to answer
(This was done in the users set up). Arrow E,F,G,H
8) The server presents the user with a screen to
ask the for answers. The user fills it in and submits it.
Arrow
A,B,C,D
9) The system validates that all is well and the
system is off to the races.
Arrow
E,F,G,H
So now lets do Other Site, this is a straight HTTP
based site.
User-> Joe
1) Joe goes to other site and requests a protected
page. The sites checks if he is already auth'd here. If not it generates a
redirect to get the auth. and personal info.
Arrow
I
2) The Auth server checks that the user auth. is
good. It also checks if this user has auth'd before through session cookies.
Again I never said it was perfect :-) If the user has authenticated already to
this auth server, then it will send the data the user has authorized for this
site. We have the concept of categories of sites as well as specific
sites.
Arrow
J
3) The data is redirected back to the Other site
through the browser. Again encrypted/xml/hashed etc.
Sooo.... things to think about. The system does
require that there be some sort of key system currently. The system does need to
know not only the user, but the servers that the user wants to use. That is a
topic for another day, suffice it to say, we have a solution although not a good
one, and not one that is implemented yet :-(
So there is a more detailed desc of what we have. I
leave it to you all to say what you want to do.
Mason |
[Prev in Thread] | Current Thread | [Next in Thread] |