If I have to choose then I prefer option #1

-  This seems to give us the most flexibility for evolving our APIs.
-  This is the current way it is implemented.  Changing this now will put
M6 at risk and would result in us pulling the API and making it
-  Worse case scenario is that we decide option #2 has many advantages in a
future release.  If this happens I think we have flexibility to deprecate
the old API and provide a new factory method to provide option #2.  This is
not ideal but it is a possibility if we find we made the wrong choice in
early API.
-  Besides embracing the JAAS API more in our API, I'm not sure what the
other advantages are.  We currently must provide our own factory class to
get ISecureContext.  This is already different from pure JAAS programming.
Also, the clients of our extensions still do implement true JAAS APIs (e.g.
LoginModule) to provide extensions to the security login features.

This type of discussion is very common in 1.0 API.  We likely will not know
how good the API is until others outside of the Eclipse team start
exercising the API.  At this point I recommend we stick with option #1.


  From:       Matthew Flaherty/Westford/[EMAIL PROTECTED]                      
  To:         equinox-dev@eclipse.org                                  
  Date:       03/25/2008 03:18 PM                                      
  Subject:    [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

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.



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/
equinox-dev mailing list

<<inline: graycol.gif>>

<<inline: ecblank.gif>>

equinox-dev mailing list

Reply via email to