Jaas LoginModule scope and session handling

Question

I might just have gotten the wrong leg up on JAAS. I started looking into JAAS because I need to provide a custom LoginModule for an application.

But every time I see an example of a LoginModule, they always define the subject as a private/protected field, which is accessed between the methods.

So my question is: What is the scope of an instance of the LoginModule? Is it a singleton which has a guarantee that initialize is always called before the other methods? Or is there a LoginModule per authenticated subject? Is it something entirely different?

And as a bonus question? How does JAAS handle session? I haven't been able to find a sessionID anywhere (Although I might have missed somewhere really obvious)

Answer 1

What is the scope of an instance of the LoginModule ?

It depends on the component that creates / manages the module.

In Java SE, the typical / intended usage of the SPI is via the LoginContext class, which, by default, lazily instantiates and initializes each of its configured modules once, just before delegating to their login method. Subsequently, the context retains references to the very same module instances until its disposal. Hence, the lifecycle of a module depends on the lifetime of its encapsulating context. And since the context's Subject is likewise only set once, the context's modules can (they actually have to in order to satisfy their contract) safely reference it until their "end of time".

The aforementioned contract and its promises naturally only hold for as long as modules are managed by the standard login context. If, for instance, an application chooses to interact with modules directly, it must also assume the responsibility of doing so while adhering to the standard login context's protocol -- or alternatively imposing further requirements on module implementations. The latter is what tends to happen in Java EE, where a vendor (read: the Java SE application in this case) may require that modules derive from their own classes and/or be accompanied by non-standard configuration.

How does JAAS handle sessions?

It does not ¹ . It was not designed with network authentication in mind really. Nor has its integration with frameworks such as Servlet and EJB been standardized.

As a standard, JAAS seeks "just" two things:

• Populate a subject with Principal s and credentials upon successful authentication.
• Augment threads' call stacks with those principals, so that authorization can later on be carried out at the granularity scale of individual call stack frames, based on both the principals' and the particular code's trustworthiness ( is the ProtectionDomain originating from http://example.com , signed by "Fred" and "Alice" , and containing the class declaring the particular invocation of method foo() , granted the specified Permission , when executed on behalf of the entity identified by Principal s { "Gill" , "HR Manager" }? ).

Anything besides those two -- sessions, network protocol messages, authentication flows, Java EE roles, and what have you -- is non-standard and at the discretion of the application or framework employing JAAS. In Java EE numerous standardization efforts have been undertaken over the years trying to bridge the gaps between the Java SE aka JAAS aka sandbox, and Java EE security models.

---

_{1 If we distanced ourselves from the web apps sphere a bit, we could view either of the LoginContext (if associated with one or multiple threads) and AccessControlContext (combined with an authenticated Subject 's Principal s first, so as to carry meaningful authorization semantics) as a kind of session. All the possible ways whereby those can be tied into some web application (framework), however, have nothing to do with standard JAAS; eg, in a Servlet setting, where authentication and authorization are application-managed, one could attach a LoginContext or its encapsulated Subject as an attribute to an HttpSession or HttpServletRequest ; or the Servlet container itself could employ the AccessControlContext under the covers in order to associate principals established during container-managed authentication with the thread(s) servicing a request (and by extension the request itself).}