Skip to main content

GF and a generic JAAS LoginModule

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
1 reply [Last post]
cpiggott
Offline
Joined: 2009-03-05

HI,

I have been searching around and see this question a few places, but
no clear answer (that I could find). I want to implement my own
LoginModule, but I don't want to have it extend
AppservPasswordLoginModule for two reasons: I don't want it to be
glassfish-specific, and I want to be able to use my own Principal.

I ran across something in pastebin from some time back:

http://pastebin.com/d79JXvQt

and that guy is having the exact same problem as me: when my
LoginModule's login() tries to use the NON-NULL CallbackHandler passed
in during LoginModule.initialize() a NullPointerException is thrown.

The way my LoginManager is actually getting invoked is a GlassFish
realm I wrote that includes this

@Override
public synchronized String getJAASContext() {
System.out.println("Returning JAAS context string");
return "customRealm";
}

My LoginModule is linked in through GF's login.conf as something like:

customRealm {
com.something.that.implements.LoginModule required;
};

So my questions are:

1) Is what I am trying to do even possible, or is there NO WAY to hook
into container-based authentication without extending
AppserverPasswordLoginModule? (I could go back to using a Jersey
servlet request filter, but I really prefer to let the container
handle the auth).

2) Can you use a LoginModule without a Realm? If so, how? I tried
putting the name of the jaas context in web.xml but that didn't work
(I didn't really think it would, anyway)

3) Suppose this is impossible. What I really need to do is attach
some extra information into the SecurityContext. It's not really
"groups" or "roles," it's really a bit of configuration information
that Jersey resource classes need to know to do their jobs,
associating a login with a customer and database names. Is there some
other way I can use something extends AppserverPasswordLoginModule,
but be able to use my own Principal rather than GF's PrincipalImpl ?

Thanks so much,

--Chris

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kumar Jayanti Guest
Offline
Joined: 2011-04-02

http://weblogs.java.net/blog/kumarjayanti/archive/2010/02/01/using-custo...

https://blogs.oracle.com/nasradu8/entry/loginmodule_bridge_profile_jaspi...

See if these help.

On Jul 8, 2012, at 2:17 AM, Christopher Piggott wrote:

> HI,
>
> I have been searching around and see this question a few places, but
> no clear answer (that I could find). I want to implement my own
> LoginModule, but I don't want to have it extend
> AppservPasswordLoginModule for two reasons: I don't want it to be
> glassfish-specific, and I want to be able to use my own Principal.
>
> I ran across something in pastebin from some time back:
>
> http://pastebin.com/d79JXvQt
>
> and that guy is having the exact same problem as me: when my
> LoginModule's login() tries to use the NON-NULL CallbackHandler passed
> in during LoginModule.initialize() a NullPointerException is thrown.
>
> The way my LoginManager is actually getting invoked is a GlassFish
> realm I wrote that includes this
>
>
> @Override
> public synchronized String getJAASContext() {
> System.out.println("Returning JAAS context string");
> return "customRealm";
> }
>
> My LoginModule is linked in through GF's login.conf as something like:
>
> customRealm {
> com.something.that.implements.LoginModule required;
> };
>
> So my questions are:
>
> 1) Is what I am trying to do even possible, or is there NO WAY to hook
> into container-based authentication without extending
> AppserverPasswordLoginModule? (I could go back to using a Jersey
> servlet request filter, but I really prefer to let the container
> handle the auth).
>
> 2) Can you use a LoginModule without a Realm? If so, how? I tried
> putting the name of the jaas context in web.xml but that didn't work
> (I didn't really think it would, anyway)
>
> 3) Suppose this is impossible. What I really need to do is attach
> some extra information into the SecurityContext. It's not really
> "groups" or "roles," it's really a bit of configuration information
> that Jersey resource classes need to know to do their jobs,
> associating a login with a customer and database names. Is there some
> other way I can use something extends AppserverPasswordLoginModule,
> but be able to use my own Principal rather than GF's PrincipalImpl ?
>
> Thanks so much,
>
> --Chris