[Shib-Users] Shibboleth 2.0.0, JBoss 4.2.2, and Active Directory.

[Thomas Kessler]

I am able to deploy and get Shibboleth to run on Tomcat 6 just fine. I would like to run it on JBoss 4.2.2. I have downloaded a fresh copy of JBoss 4.2.2 and uncommented the "<application-policy name = "other"> element" in login-config.xml. The only other change I made was to configure SSL support. For some reason when a user submits his/her authentication information to Shibboleth via the login.jsp, Shibboleth does not connect to Active Directory. I have turned on logging for "edu.vt.middleware.ldap" and get a full report back when running on Tomcat, however when running on JBoss 4.2.2 there authentication against AD does not occur and I only get this at the end of the log:

07:58:49.329 INFO [Shibboleth-Access:72] - 20081030T125849Z|192.180.1.10|192.180.1.11:8443|/profile/SAML2/Redirect/SSO|

When running on Tomcat I get all of the edu.vt.middleware.ldap output just after the line above.

Has anyone else ran into this issue?

TK

[Ahmed Choudhry]

Thomas,

We are running on JBoss 4.2.3 (previously 4.2.2).

We added another policy to login-config.xml, named "ShibUserPassAuth".
It appears that JBoss does not honour the creation of JAAS contexts
by the application. So, it would be logical to assume that the
ShibUserPassAuth context is not created at the application level, but
the login part does find it, as JBoss has pre-defined it at the
container level. Here is our config - please try it out - if it works
for you also, we can add it to the wiki:

This should work with ActiveDirectory also with the usual caveats
about AD such as the global catalog port, referrals etc.

<application-policy name="ShibUserPassAuth">
<authentication>
<login-module code="org.jboss.security.auth.spi.LdapLoginModule"
flag="required">
<module-option name="java.naming.factory.initial">
com.sun.jndi.ldap.LdapCtxFactory
</module-option>
<module-option name="java.naming.provider.url">
ldap://xxxxx:10389/
</module-option>
<module-option name="java.naming.security.authentication">
simple
</module-option>
<module-option name="principalDNPrefix">uid=</module-option>
<module-option name="principalDNSuffix">
,ou=users,o=xxxxxxxxx</module-option>

<module-option name="rolesCtxDN"> ou=Roles,o=trc </module-option>
<module-option name="uidAttributeID">member</module-option>
<module-option name="matchOnUserDN">true</module-option>

<module-option name="roleAttributeID">cn</module-option>
<module-option name="roleAttributeIsDN">false </module-option>
<module-option
name="java.naming.security.principal">uid=bind,ou=system</module-option>
<module-option
name="java.naming.security.credentials">xxxxxxxxxxxxxxx</module-option>
</login-module>
</authentication>
</application-policy>

2008/10/30 Thomas Kessler <djk...@gmail.com>:

--
Ahmed Choudhry
General Manager,
شركة الخليج للنظم البينة
Gulf Open Systems Co. (Oman)
P.O. Box 395
P.C. 111 CPO Seeb, Sultanate of Oman
Phone: +968 24475299
Mobile: +968 95335428

[Brent Putman]

It would appear that JBoss overrides the default JAAS login config provider and sets its own implementation for the installed JRE runtime instance of that.  So the Shib conf/login.config is essentially ignored.  We do mention the possibility of JRE or container-specific JAAS policy config in the UsernamePassword LoginHandler schema and wiki docs, but perhaps we need to highlight this better.  Especially since in this case it seems to be the default of the container, and not a conscious user choice.

What Ahmed suggests below would seem like a good solution (albeit I'm not a JBoss expert).  Note also that you could take his example template, and instead use the VT LDAP JAAS module, which the Shib project team can support better for Shib purposes.  You are of course free to use another JAAS module, like the JBoss LDAP one below, but you're obviously on your own for supporting that on module-specific behavior or problems.


Background:
This is happening because usage of the Shib conf/login.config JAAS policy file assumes that the JAAS  javax.security.auth.login.Configuration instance that is installed as the global one in the JRE runtime is one that sources its config input from the policy config file indicated by system property java.security.auth.login.config.  JBoss apparently installs a different Configuration impl that doesn't do this, so assumption breaks down.

We could theoretically insulate ourselves from this container-specific behavior by using a JAAS Configuration instance other than the global one installed in the JRE runtime config.  I just spent some time looking at that.  Unfortunately, it appears that some of the API functionality necessary to achieve this in a platform and JRE-independent manner was only introduced in Java 1.6.  So it does not appear that that is an option at present, since we will need to continue to support 1.5 for some time, at least until it's EOL'ed.


--Brent