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 internal.provisional. - 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. Tom From: Matthew Flaherty/Westford/[EMAIL PROTECTED] To: email@example.com 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 /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/ _______________________________________________ equinox-dev mailing list firstname.lastname@example.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________ equinox-dev mailing list email@example.com https://dev.eclipse.org/mailman/listinfo/equinox-dev