geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo Web Interceptors, WebSSO with Authentication Proxy
Date Fri, 24 Feb 2006 18:36:07 GMT

On Feb 24, 2006, at 8:44 AM, Aaron Mulder wrote:

> On 2/24/06, David Jencks <david_jencks@yahoo.com> wrote:
>> 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.
>
> OK
>
>> I think this could be switched on or off by changing the login module
>> you use.
>
> I was wondering whether we'd even both grabbing the credential header
> or just grab the username and group list.  I agree that if the web
> container provides the credential then it's up to the login module to
> decide whether to store it or not, and in fact you could just layer on
> our existing credential saving login module if we use the same
> callback handlers.
>
>> 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.
>
> I was assuming we would not re-authenticate, under the assumption that
> the SSO service may well have access to more information than Geronimo
> does (in the architectures like this I've seen, the app server doesn't
> have a link to the LDAP server).  The reason I suggested a LoginModule
> is that it would work (assuming some callback standardization) and all
> our plumbing for that is in place -- it would require no code changes
> in the security module and you could still use our auditing feature,
> etc.

Thinking about this a bit more, I think one solution would be to have  
a "RequestAuthenticator" that stuffs the request object into a  
Callback.  Then the login module(s) can figure out how to extract the  
necessary info from the request and, depending on the setup, either  
construct a  Subject or actually authenticate.  I think this would   
be  a pretty general solution, since the part that extracts the info  
from the request would be pluggable.

thanks
david jencks

>
> Thanks,
>     Aaron
>
>>> On 24 Feb 2006 11:12:46 +0100, sepima@poczta.fm <sepima@poczta.fm>
>>> 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, sepima@poczta.fm
>>>>>> sepima@poczta.fm> 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
>>>>
>>>>
>>
>>


Mime
View raw message