[Security & JAAS/JBoss] - Re: Minimal JBoss config to use GSSAPI/Kerberos acceptSecCon
by quinntaylor
Chris, if you're local to Silicon Valley, I just might buy you a lunch! I don't know where you found something that suggested specifying the GSS config as an <application-policy> entity, but that definitely worked for me. (I knew it had to be something in login-config.xml, but I wouldn't have guessed that this is how you do it. Genius!)
For my application, I have a custom Kerberos configuration, so I added the following lines in a run.conf file (used by run.sh):
# System properties for Kerberos / GSS
| JAVA_OPTS="$JAVA_OPTS -Djava.security.krb5.conf=/path/to/krb5.conf"
| JAVA_OPTS="$JAVA_OPTS -Djavax.security.auth.useSubjectCredsOnly=false"
Since my server uses a keytab file with many different principals (and acts as acceptor for any of them), my code doesn't need to directly connect to the KDC, so I eliminated some of those module options. Here's what I have (edited, of course)...
<application-policy name="com.sun.security.jgss.accept">
| <authentication>
| <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
| <module-option name="realm">REALM.EXAMPLE.COM</module-option>
| <module-option name="isInitiator">false</module-option>
| <module-option name="useKeyTab">true</module-option>
| <module-option name="keyTab">/path/to/krb5.keytab</module-option>
| <module-option name="storeKey">true</module-option>
| <module-option name="doNotPrompt">true</module-option>
| </login-module>
| </authentication>
| </application-policy>
I've actually found that I can do without the LoginContext song and dance. I don't know if it's because the servlet executing the code is SSL-secured, or if it's something else. In any case, in my code, right before I do step 5, I include this line of code to specify the principal from the keytab for which I need to retrieve a credential:
System.setProperty("sun.security.krb5.principal", principalName);
Thanks again, you've been a tremendous help. No more tearing my hair out and cursing the JBoss security manager!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214649#4214649
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214649
17 years, 1 month
[JBoss Tools (users)] - Re-deploying
by jcw_at_mjc
I've just started trying 3.0.0CR2 on Ganymede (from 2.1.2 on Europa) so am probably doing something stupid, or the wrong way, but I can't find an easy way to re-deploy my WAR to my JBoss server.
When I've changed my code, I generate the WAR by running an Ant script. I used to then just right-click on the WAR and select 'Deploy to server'. Now that's changed to 'Make undeployable', and I can't find a way to get my new code on to the JBoss server. Things I've tried are:
Making the WAR undeployable then making it deployable again.
Selecting 'Publish' from the JBoss server context menu.
Cleaning (& hence rebuilding) the project.
Refreshing the WAR file.
Some of these lead to the server displaying undeploy and deploy messages, but I still get the old behaviour.
Can anyone offer me some suggestions?
Thanks
James
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214645#4214645
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214645
17 years, 1 month
[Security & JAAS/JBoss] - Followup: GenericHeaderBasedAuthentication
by 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
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4214637#4214637
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4214637
17 years, 1 month