[Auth]How the system can work with app.servers

[Mason Ham]

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.

http://dotgnu.org/graphics/MasonHam1.jpg

 

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