The way I have implemented my own TAI is this. 1) Created my own LDAP Realm class that allows me to find identities based on their cn or uid 2) Created my own valve, that checks to see if the Single Sign Cookie is present, if not then check to see if in the PipeLine there is an instance of an AuthenticatorBase (implies that the request requires authentication and that no credentials have been supplied) then reads the Request Headers and extracts the necessary information (have not done iv_groups but simple to add it) and then using the AuthenticatorBase object register them. This gives them the Single Sign On cookie.
Problems with this approach (mainly due to a lack of understanding how Tomcat works) is that when the session times out it tries to re-register them using the credential supplied (in this case I am using a null password) and the basic method. This can be easily solved now by creating a Custom Authenticator class and using that. I know this is a very basic approach, but so far it works for me and is a work in progress piece for me to learn Tomcat fundamentals so that I can then expand into the Geronimo space as I know TAM and WebSphere. If you want my source code then private message me and I will supply. -----Original Message----- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Saturday, 25 February 2006 2:40 AM To: [email protected] Cc: Simon Godik Subject: Re: Geronimo Web Interceptors, WebSSO with Authentication Proxy On Feb 24, 2006, at 4:46 AM, Aaron Mulder wrote: > So it sounds like we need to accept a "trusted" username and group > list from the HTTP request? It would be easy enough to prepare a > LoginModule to handle that. The problem is, I suspect we'll need a > code change to the web containers so that they could provide HTTP > request information to the LoginModule on demand. I imagine we'd > provide a way in the geronimo-web.xml to list the user and group > property names (iv-user, iv-groups) that should be passed in to the > LoginModule on request. At least for Jetty I think we would need another Authenticator to replace e.g. the FormAuthenticator or BasicAuthenticator. This could fish the info out of the request and put it into a CallbackHandler for use by a login module. Installing this is going to require some changes in the JettyModuleBuilder. After you write the Authenticator it would be pretty easy to add code to install it. We'll have to come up with some flag in the jetty plan to indicate what you want. > > Can I just ask a couple more questions? > > 1) How is the information attached to the request? Is it an HTTP > header or a get/post parameter? > > 2) What is the format of the group list for iv-groups? > > 3) Would you need the credentials for anything, e.g. if it's a > password, to turn around and log into a web service or CORBA service? I think this could be switched on or off by changing the login module you use. It's not clear to me whether this is normally configured so that - geronimo will trust the security info from the authentication server and simply stuff it into a Subject or - geronimo will re-authenticate based on the info from the header. If the first, I wonder if a login module is really the most appropriate approach. I'm hoping to hear what Simon Godik thinks. thanks david jencks > > Thanks, > Aaron > > On 24 Feb 2006 11:12:46 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: >> First, I%u2019d like to explain WebSEAL functionality in few words. >> >> WebSEAL is some kind of the reverse proxy with authentication and >> authorization extensions. WebSEAL is part of TAM (Tivoli Access >> Manager). Usually it works in front of HTTP or Application Server >> in DMZ. Diagram below shows the hi-level architecture (flow of >> request) with WebSEAL: >> >> [user] ---> [WebSEAL] ---> [firewall] ---> [HTTPServer] ---> >> [Geronimo] >> >> Obviously Firewall and HTTPServer are not mandatory and for our >> consideration I propose analyse this case without it. >> >> One instance of WebSEAL can work with more than one application >> (or web) server. WebSEAL provides functionality like Web SSO, a >> lot of authentication mechanisms, Step-up of authentication and a >> few more. >> >> After WebSEAL authenticates the user, it adds his username (iv- >> user), groups (iv-groups) and credentials (iv-creds) to the >> request which is forwarded to the backend-server. I hope Geronimo >> can use this information to authenticate user automatically. >> Please correct me if I am wrong, my proposition is to use the >> Interceptor to do it. My problem is that I don%u2019t know how to >> change the interceptor in Geronimo-jetty ;( >> >>> I'd like to be able to plug third-party authentication providers >>> like >>> this into Geronimo. It's possible we can do it with a custom >>> security >>> login module. >> >> I know we can but I want to use WebSEAL or any other >> Authentication Proxy for authentication and pre-authorization of >> the user requests. >> >>> How much do you know about the WebSEAL API? >> >> I hope I know this API well :) >> >>> If there >>> was some remote call we could make, for example, to supply a >>> username >>> and password and get back whether it was valid and a list of groups, >>> that would be pretty easy to integrate. >> >> Of course TAM has API to do it. To be precise, I made it and this >> is works fine. But, I hope you understand me, that it does not >> meet my needs. >> >>> But I haven't heard of >>> WebSEAL before, so I'm not even sure if it operates on usernames and >>> passwords at all. >> >> Yes, WebSEAL is based on LDAP Server and provides authentication >> mechanism based on user login/password. >> I hope my explanation is clear enough, but if not I will try to >> answer for any questions. >> >> Thanks, >> sebo >> >> >> >>> On 23 Feb 2006 10:26:32 0100, [EMAIL PROTECTED] >>> >[EMAIL PROTECTED]> wrote: >>>> Hi All, >>>> >>>> I am looking for information about Geronimo%u2019s Web Container >>> Interceptors. It is preferred for me to use Jetty but Tomcat is >>> good as >>> well. >>>> I plan to integrate Geronimo with Authentication Proxy like >>>> WebSEAL from >>> TAM. If you look at WAS concept, there is TAI mechanism which >>> integrates >>> Authentication Proxy with Application Server. Does Geronimo have >>> something >>> like TAI from WAS? >>>> >>>> I thing it will be good to add my own interceptor or change the >>>> standard >>> SecurityContextBeforeAfter one. Maybe, it will be enough to use >>> my own >>> Authenticator. What do you thing about it? >>>> >>>> Ps >>>> I tried to use Tomcat SSO (ValveGBean) but it does not work. >>>> >>>> This is part of plan file: >>>>> gbean name="SecondValve" >>> class="org.apache.geronimo.tomcat.ValveGBean"> >>>>> attribute name="className">my.own.SSOClass>/attribute> >>>>> /gbean> >>>> >>>> Tomcat calls this SSOClass but it is before Geronimo loads Security >>> Policy and when I add Credential to the request, it throws >>> NullPointerException. >>>> If someone is using this Tomcat SSO mechanism, any advices will be >>> helpful for me. >>>> >>>> >>>> Environment: >>>> Linux RedHat 4 update 2 >>>> IBM JDK 1.4.8 >>>> Geronimo 1.0 >>>> Tivoli Access Manager 6 >>>> Tivoli Directory Server 6 >>>> >>>> best regards, >>>> sebo >>>> >>>> >>>> ------------------------------------------------------------------ >>>> Jestes poszukiwana. Szuka Cie wysoki brunet! >>>>>> http://link.interia.pl/f190c >> >>>> >>>> >>> >>> >> >> >> >> --------------------------------------------------------------------- >> - >> Ocen dziewczyny Playboya!!! >>> http://link.interia.pl/f190f >> >> -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.0/269 - Release Date: 24/02/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.0/269 - Release Date: 24/02/2006
