[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Providing ILoginContext vs. extending LoginContext


One of the topics we discussed at the Equinox meeting today was the auth API.... Opening up the conversation to the wider audience. We add a few notable pieces of function on top of JAAS:

1) The ability to wire together JAAS components via extension points
2) The ability to monitor events in the JAAS login lifecycle
3) A lazy login when getSubject() is called

Currently there are two schools of thought.

1) A factory (ISecurePlatform) that returns an interface (ISecureContext) that looks much like -and wraps- a JAAS LoginContext (plus add/remove listener, modified getSubject)
2) A factory (LoginContextFactory) that returns an actual LoginContext class (EquinoxLoginContext extends JAAS LoginContext and overrides getSubject()), and a listener registration facility (ListenerRegisterer or the like) that takes an EquinoxLoginContext (or perhaps even a plain-old JAAS LoginContext)

See LoginContext: http://java.sun.com/j2se/1.5.0/docs/api/index.html?javax/security/auth/login/LoginContext.html

We currently implement #1. Doing #2 has a little bit of funk to it. One problem is that getSubject() does not throw an exception - we cannot extend this method to add the exception. One way around this could be to return an 'anonymous' subject - either an empty one or one with a contractually agreed 'anonymous' principal. This is a fairly reasonable pattern.

The basic dilemma boils down to whether we extend LoginContext (which is not final), or wrap it up in our own thing.

Thoughts?

-matt

---
Matt Flaherty
Security Project Lead, Lotus Notes & Eclipse Equinox
External:
http://www.eclipse.org/equinox/incubator/security/
Internal:
https://cs.opensource.ibm.com/projects/eclipsesec/