GenericHeaderBasedAuthentication

[sfisque]

using JBoss AS 4.2.3-GA on solaris, jdk 1.5.0

i'm trying to configure GenericHeaderBasedAuthentication for use with Oracle's OBLIX SSO solution.

what i cannot figure out from the documentation is what the syntax of the values for "httpHeaderForSSOAuth" and "sessionCookieForSSOAuth" are. the examples show three values that are comma separated. what are the pieces of these strings and how do they map to functionality that GenericHeaderBasedAuthentication offers?

i'm sure configuring this valve is fairly easy, but for the lack of clear documentation, it is beyond me.

any help is appreciated.

(and yes, i've been googling this for hours :-)

TIA

== stanton

[anil.saldhana]

httpHeaderForSSOAuth="sm_ssoid,ct-remote-user,HTTP_OBLIX_UID"
 sessionCookieForSSOAuth="SMSESSION,CTSESSION,ObSSOCookie"

The first value is basically what oblix will be sending as the username in the http header. The second one is what oblix will use as a session cookie. Do you have the header names passed by oblix?

[sfisque]

httpHeaderForSSOAuth="sm_ssoid,ct-remote-user,HTTP_OBLIX_UID"
 sessionCookieForSSOAuth="SMSESSION,CTSESSION,ObSSOCookie"

The first value is basically what oblix will be sending as the username in the http header. The second one is what oblix will use as a session cookie. Do you have the header names passed by oblix?

i dug up the source so it appears the comma delimited list is a multiple choice of possible values the driver looks for.

from what i've gathered from the client, the Header is going to be XYZUSER. they are not going to push the session_id (they say we should just trust the user_id published in the Header).

i've configured my context.xml to have the valve in question. problem is, i tried to request the main page using curl and pushing the Header with a value that maps to a user in the app user table (we use the DatabaseServerLoginModule to handle mapping users and roles) but it always sends me the login page.

what i was expecting (maybe erroneously) that the GenericHeaderAuthenticator would intercept the request for the form and inject the user_id from the Header and then the DatabaseServerLoginModule (configured with "useFirstPass") would recognize we have a user_id and just map the roles.

my followup questions are:

1) if we are using an application policy in login-config.xml, does this negate the Valve in the context.xml or do they not play nicely together, requiring me to create a JAAS module and configure it in the login-config.xml?

2) if JAAS and the GenericHeader valve do not play nicely, can the GenericHeader be configured as a login module in login-config.xml?

TIA

== stanton

[sfisque]

i turned up the logging to get TRACE events from org.jboss.web.tomcat.security and i dont see any events coming from the GenericHeaderAuthenticator, which should be echoing to the log file.

i double checked the syntax of the Valve tag in my context.xml file and it appears sane.

besides deploying the webapp with a context.xml, are there any other steps that need to be done to ensure the Valve gets loaded and registered? i'm running on AS 4.2.3-GA on java 1.5.0 installed on solaris 10 (i386).

== stanton

[sfisque]

i got the context.xml to load.

for anyone going down this road, it appears the GenericHeader valve MUST have the session cookie pushed by Oblix.

i'm going to have to subclass it and remove the dependency on the cookie, to fit the target environment.

== stanton

[sfisque]

so now i have a custom LoginModule that subclasses the GenericHeader module that is included in jboss-as 4.2.3. the module successfully extracts the user_id from the header, sets super.loginOk to true and puts the created Principal into javax.security.auth.login.name.

when i watch the TRACE messages in the server.log, i see the next few lines that say:

2009-03-03 09:42:09,796 INFO [com.kryptiq.security.jboss.HeaderInjectionLoginModule] HeaderInjectionLoginModule:creating principal
2009-03-03 09:42:09,796 INFO [com.kryptiq.security.jboss.HeaderInjectionLoginModule] HeaderInjectionLoginModule:login returns:true
2009-03-03 09:42:09,802 TRACE [org.jboss.web.tomcat.security.JBossSecurityMgrRealm] User: admin is NOT authenticated
2009-03-03 09:42:09,802 TRACE [org.jboss.web.tomcat.security.JBossSecurityMgrRealm] End authenticate, principal=null
2009-03-03 09:42:09,802 TRACE [org.jboss.web.tomcat.security.ExtendedFormAuthenticator] forwardToErrorPage
2009-03-03 09:42:09,802 TRACE [org.jboss.web.tomcat.security.ExtendedFormAuthenticator] SessionID: 0C6DCFB37AFF70517F44B950CCAA64B3
2009-03-03 09:42:09,802 TRACE [org.jboss.web.tomcat.security.ExtendedFormAuthenticator] Setting j_username = null
2009-03-03 09:42:09,802 TRACE [org.jboss.web.tomcat.security.ExtendedFormAuthenticator] Setting j_exception = javax.security.auth.login.LoginException: Security Exception

i'm not sure why my login module (which is returning true from login()) is begin rejected by JBossSecurityMgrRealm, saying the user is not authenticated.

what i am trying to achieve is to have this custom LoginModule intercept the presence of an injected Header, and authenticate the user, and then have DatabaseServerLoginModule trust this authentication, bypass its auth phase, and provide the roles. thus the desired chain is:

1) is the user sending a pre-authenticated Header?
2) if so, authenticate them so DatabaseServerLoginModule can provide the Roles
3) if not, then DatabaseServerLoginModule can send the user the login screen and authenticate them itself, and then provide the Roles.

my estimation is that there is some "interplay" between the modules that i am missing. is there a special attribute or sequence of method calls that must be performed so that DatabaseServerLoginModule will trust the previously authenticated user and just provide the roles?

TIA

== stanton

[sfisque]

basically, i tried subclassing UserPasswordLoginModule and this proved fruitless. i eventually just subclassed AbstractServerLoginModule. it seems the fact that identity and the other attributes of AbstractServerLoginModule are private was causing me all sorts of headaches.

i would suggest either of the two avenues for the implementations in the org.jboss.security.auth.spi package:

1) either mark the classes as final so that it is apparent to developers that these classes are not designed for subclassing.

2) change the attributes to protected so that subclasses are given proper access to the internal attributes.

TIA

== stanton

[sfisque]

"sfisque" wrote:
it seems the fact that identity and the other attributes of AbstractServerLoginModule are private was causing me all sorts of headaches.

the above should read "UserPasswordLoginModule", not AbstractServerLoginModule.

sorry for the confusion. [they really nead to add an "EDIT" option to the forum]

== stanton