[keycloak-dev] Why BearerTokenLoginModule?

[Marek Posolda]

I am using it for hawtio at this moment. Right now I have hawtio 
basically working including login, logout and logout from different app. 
There are still kinks to address (mainly on client side) and also more 
testing on different servers (I am using tomcat for development now).

Client side is javascript application and is done with keycloak.js. The 
authentication of server on hawtio is not based on servlet security but 
on JAAS. The client is expected to send username/password in 
Authorization header with BASIC scheme. Then there is servlet filter on 
server-side, which parses Authorization header and delegates 
authentication to JAAS where it sends username and password via 
CallbackHandler.

What I am doing right now is sending accessToken as password in 
Authorization header. I am using:
username: bearer (really hardcoded string atm)
password: <access_token>

BearerTokenLoginModule is then able to verify accessToken and establish 
jaas identity expected by hawtio. Note that login module is used just 
for bearer authentication of accessToken and it doesn't need to interact 
with HTTP.

I can also investigate the approach based on adapters. Basically adapter 
will establish servlet security and then hawtio AuthenticationFilter 
would need to be replaced in web.xml with some other filter, which will 
be able to establish hawtio security context (which is mainly about 
saving jaas Subject into http session) based on servlet authentication.

Fact is that JAAS approach seems to be less invasive and I am quite sure 
that it will work on all servers, which hawtio supports. I still need to 
investigate and test a bit more, everything is in prototype stage...

I am out on Monday (public holidays) but will continue on Tuesday.

Marek

On 14.11.2014 14:50, Bill Burke wrote:
> What is the purpose of this?  We have adapters to do this kind of stuff.
>    A LoginModule doesn't remove the need for an adapter as you still need
> to extract and propagate the token in the protocol layer.  I've already
> been down this road and it is a dead end.
>