<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    On 3/23/12 5:34 AM, Rod Widdowson wrote:
    <blockquote cite="mid:005701cd08d8$1bbea710$533bf530$@com"
      type="cite">
      <pre wrap="">

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".</pre>
      <br>
    </blockquote>
    <br>
    As Rod said, it happens via Spring wiring.<br>
    <br>
    Additionally, there is something a little unintuitive about the way
    the JAAS config file parameter there is handled.&nbsp; 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 '
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <span class="pygments-s">java.security.auth.login.config'.&nbsp; 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.<br>
      <br>
      Using the system property means that the config specified there
      becomes the single JAAS global Configuration.&nbsp; Therefore, it's not
      possible to have different&nbsp; JAAS configurations for different
      handlers (nor for other non-IdP JAAS based apps/things running in
      the same container).&nbsp; 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.&nbsp; If you were to
      specify multiple config locations, only one of them would "win",
      depending on the ordering, so that doesn't work.<br>
      <br>
      Clearly this is suboptimal.&nbsp; It would be possible to fix by
      eliminating Java 5 support and targeting a minimum of Java 6.&nbsp;
      That won't happen in IdP v2.&nbsp; 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.&nbsp; However, based on current
      design the authN components shipped as a part of IdP v3 will no
      longer be based on JAAS.<br>
      <br>
      --Brent<br>
      <br>
    </span>
  </body>
</html>