[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Providing ILoginContext vs. extending LoginContext
|
I also agree with option #1, but would like to make sure that plugins
have extension points to specifically be able to hook into an existing
login process (e.g. add principals/credentials to a Subject before the
relevant collections are made read-only...i.e. prior to
loginmodule.commit()) as per this enhancement request:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=200299
I'm sorry I haven't been able to go over the existing APIs to verify
this is the case...they've been changing rapidly and I have had other
time constraints.
Scott
Thomas Watson wrote:
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
Inactive hide details for Matthew Flaherty---03/25/2008 03:18:16
PM---One of the topics we discussed at the Equinox meeting todMatthew
Flaherty---03/25/2008 03:18:16 PM---One of the topics we discussed at
the Equinox meeting today was the auth API.... Opening up the
conversation to the wider audie
From:
Matthew Flaherty/Westford/IBM@Lotus
To:
equinox-dev@xxxxxxxxxxx
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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
------------------------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
