Location of configuration file parameter UsernamePassword Login Handler

[Marco Zanini]

Hi to all,

I'm developing an extension of shibboleth for the LoginHandler and I want to use jaas authentication. For this reason, I'm looking at the code of UsernamePassword LoginHandler but I cannot understand where the jaas configuration file is read.In the Jaas documentation, linked by the shibboleth wiki (http://docs.oracle.com/javase/1.5.0/docs/guide/security/jaas/tutorials/LoginConfigFile.html) I cannot find relevant information. It suggest to tell java the location of the configuration file trought the command line or the java.security file but I didn't nor of these two and UsernamePassword LoginHandler works great anyway! The problem is that my Handler, which for authentication has the same code, cannot find the configuration file. How can I do?

In handler.xml we can specify configuration file as a parameter but then I cannot see where in the code this parameter is acquired, UsernamePasswordLoginHandler takes as input "servletUrl".

Many thanks,

Marco

[Rod Widdowson]

You have forgotten about the Spring bits of the code (that big warning at the top of
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPDevCustomExtension) is really important.

try

edu.internet2.middleware.shibboleth.idp.config.profile.authn.UsernamePasswordLoginHandlerBeanDefinitionParser

(in shib-idp).

--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net

[Marco Zanini]

Ah so you discovered me! :) Yes I skipped that part, not for disregard but because of the lack of time. Thank you anyway, now it's working! 

By the way, the missing method to set the configuration file was: System.setProperty("java.security.auth.login.config", jaasConfigurationURL); 

Many thanks,

Marco

[Brent Putman]

On 3/23/12 5:34 AM, Rod Widdowson wrote:

In handler.xml we can specify configuration file as a parameter but then I cannot see where in the
code this parameter is acquired, UsernamePasswordLoginHandler takes as input "servletUrl".

As Rod said, it happens via Spring wiring.

Additionally, there is something a little unintuitive about the way the JAAS config file parameter there is handled.  As you can see in the bean definition parser class that Rod referenced, the config file value is merely set as the value of Java system property ' java.security.auth.login.config'.  It's done this way b/c IdP v2 targeted Java 5, and prior to Java 6, there was no implementation-independent way to parse a JAAS config file into a JAAS Configuration instance.

Using the system property means that the config specified there becomes the single JAAS global Configuration.  Therefore, it's not possible to have different  JAAS configurations for different handlers (nor for other non-IdP JAAS based apps/things running in the same container).  So all the JAAS-based handlers would need to point to the same file, and use different application names to reference different named blocks in the config.  If you were to specify multiple config locations, only one of them would "win", depending on the ordering, so that doesn't work.

Clearly this is suboptimal.  It would be possible to fix by eliminating Java 5 support and targeting a minimum of Java 6.  That won't happen in IdP v2.  IdP v3 will target (at least) Java 6, perhaps even 7 (can't remember off-hand where that discussion went), so would be possible there.  However, based on current design the authN components shipped as a part of IdP v3 will no longer be based on JAAS.

--Brent

[Chad La Joie]

Right, just for the record. IdPv3 will initially be compiled targeting
Java 6. When we release we will list the minimum requirements at Java
7. In the future, when a couple OSes have had time to get on the band
wagon, we'll switch to compiling specifically for Java 7.

On 3/23/12 12:37 PM, Brent Putman wrote:
> IdP v3 will target (at least) Java 6, perhaps even 7 (can't
> remember off-hand where that discussion went), so would be possible
> there.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered