geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [UsernameToken] WS-Security at Server Side in Geronimo
Date Mon, 13 Jul 2009 19:04:22 GMT

On Jul 13, 2009, at 11:21 AM, Jarek Gawor wrote:

> David,
> With the UsernameToken profile the password can also be sent in a
> digest form. Can the ContextManager API be used with authenticate with
> such password? Or is something else needed?

Whether or not you accept the specific interfaces of jsr 196/jaspic  
the ideas are useful in thinking about this stuff.

A message arrives and needs authentication.
First the container figures out if the transport is OK and whether  
authentication is needed.
Depending on the app the container figures out an authenticator to use.
The message is fed into the authenticator which tries to extract  
identity info and credentials from the message.  If necessary it can  
conduct a message dialog with the client in order to request this  
(e.g. basic auth challenge, redirect to login form, openid dialog, etc  
After the identity info is extracted the authenticator can use a login  
service provided by the container to validate the credentials.
The results of this auth process are then used to check that the user  
has access to the resource, and the message processed.

(I'll skip the stuff about securing the response)

In geronimo, the ContextManager.login methods correspond to the login  

What we need here is some kind of authenticator to extract the  
credentials from the message, conduct a dialog if necessary, and feed  
the credentials into the login service.  I don't know what kind of  
info can be in the message.  If the info about the form of credentials  
is contained in the message rather than, as with web apps, in the web  
app deployment info, then the authenticator needs to be able to handle  
both basic and digest auth info.  If the web service is deployed so as  
to accept only one of basic and digest info, then you probably want  
two authenticators, the one used depending on how the web service is  

BTW while considering the ejb ws transport security enforcement for  
tomcat and how to align it with what I wrote for jetty I started  
looking at jaspi enabling tomcat.  There are also some technical  
problems with our jacc support in tomcat that this would fix.  I  
really don't want another long drawn out feature but if I can get this  
working today I'll probably put it in our 2.2 tomcat stuff.  This  
might make jaspi a more plausible implementation route for this stuff.

david jencks

> Jarek
> On Fri, Jul 10, 2009 at 4:46 PM, David  
> Jencks<> wrote:
>> On Jul 10, 2009, at 1:04 PM, rahul.soa wrote:
>> Hello Devs,
>> I am configuring the usernameToken* security configuration in  
>> geronimo (for
>> CXF). So far, I have configured it for Client side :).
>> For the server side, I have tried it with hard-coded values and  
>> that works.
>> Now, I dont know what *APIs* (server authorization apis or other  
>> apis) I
>> should use to authenticate the user based on the usernameToken
>> (username/password). In other words, how can we configure/enable the
>> ws-security (usernameToken) at **server side** in Geronimo?
>> How and what information we need to pass to enable the ws-security  
>> on the
>> server side?
>> I am stuck on this point and I really need your suggestions and  
>> pointers.
>> If you want a theoretically portable solution you should probably
>> investigate writing a jaspi auth module for this.  This would  
>> probably take
>> a while and at the moment only work with jetty7.
>> For a geronimo-specific solution you need to:
>> 1. authenticate the user by calling
>> realm,
>> CallbackHandler callbackHandler, Configuration configuration).
>> or
>> ContextManager..login(realm, callbackHandler);
>> Generally for the first call you'd get a Configuration from a
>> GenericSecurityRealm component.  If you want something less  
>> configurable but
>> quicker use the second call; the configuration named by the realm  
>> name must
>> be already registered with the GeronimoLoginConfiguration.
>> You'll get back a LoginContext containing the authenticated Subject.
>> 2. To make the results available to container managed security call
>> ContextManager.setCallers(subject, subject);
>> try {
>>   //do work, process message, etc etc
>> }finally {
>>     ContextManager.clearCallers();
>> }
>> hope this helps -- ask if you aren't clear on how to proceed.
>> david jencks
>> Please help me in this.
>> Thank you in advance.
>> Best Regards,
>> Rahul
>> * to authenticate the user based on the usernameToken (username/ 
>> password) in
>> the SOAP header

View raw message