Open GoogleCodeExporter opened 9 years ago
I will have a look at that later today...
:-)
Original comment by aike.som...@gmail.com
on 9 Nov 2010 at 9:35
I just looked at some of the underlying code and am not sure what exactly you
are trying to access, can you be a little more specific?
Original comment by aike.som...@gmail.com
on 9 Nov 2010 at 10:08
AuthenticRoast gives you multiple ways to acquire authentication information
from the user. The Tomcat 'Realm', e.g. a JAASRealm, encapsulates what database
you are checking this authentication material against: JNDI, LDAP, a flat file,
etc. This can be a JAAS realms into which you can provide your own JAAS
modules. Glassfish also has a way to provide your own JAAS modules. I have
systems that need to authenticate using any of {SSL client certs, tickets,
forms} as authentication sources, which AuthenticRoast would do for me. My
system already has several JAAS modules already configured into Tomcat (soon to
be Glassfish). I need a way to access either the realm or its underlying login
configuration so I can directly or indirectly call my JAAS modules. Otherwise I
have to get the login configuration information into the pluggable
authenticators somehow so I can construct my own JAAS LoginModule in each of
them, and I don't see how to do that cleanly given there are several web-apps
that share the JAAS modules and will ultimately share the
PluggableAuthenticators too. Also that goes against the orthogonalization of
auth mechanisms as per Roast and auth realms as per JAAS.
Original comment by EsmondP...@gmail.com
on 9 Nov 2010 at 11:32
The Login Bridge section of JSR 196 talks about how this could be done.
Basically the AuthenticationRequest should contain a LoginModule that is
created for every request needing authentication, and you should define how the
Configuration object is configured, typically via a filename relative to the
application base.
There are further ramifications of this but they would indicate API changes.
JAAS is built around populating a javax.security.auth.Subject with Principals,
some of which identify the use and some of which identify his roles. This would
get rid of your SimplePrincipal for example, which already conflicts with
several things in my systems, as I already had UserPrincipals of my own and was
already battling with Tomcat's GenericPrincipal.
Original comment by EsmondP...@gmail.com
on 10 Nov 2010 at 10:07
I think I see how to do this, in fact I've drafted a
name.aieksommer.authenticator.jaas package that does it. It doesn't put you in
contact with the underlying JAAS but it gives you a central way to use the same
one by supplying configuration information to a JAASManager. The package also
contains JAAS implementations of the BasicAuthenticor, FormAuthenticator,
TicketAuthenticator, SSLClientAuthenticator, and LogoutManager, that turn out
to be all you need - you don't have to write your own derived classes at all. I
will keep you posted on progress, should have it working next week if the
fundamental design makes sense.
Original comment by EsmondP...@gmail.com
on 11 Nov 2010 at 7:57
[deleted comment]
Please see attached draft API for comment.
Original comment by EsmondP...@gmail.com
on 12 Nov 2010 at 3:59
Attachments:
Here it is. API stable and Javadoc pretty clean. The ObjectManager and
JAASAuthContextImpl classes belong in the Impl module, everything else in the
Extras module. Alternatively you could put it all into a new JAAS module I
guess but you'd be mixing things up. I'm not really convinced about your
existing module structure actually, I would move the current Extras into the
API myself.
Original comment by EsmondP...@gmail.com
on 2 Dec 2010 at 6:11
Attachments:
Logging bug in this, reattached.
Original comment by EsmondP...@gmail.com
on 7 Dec 2010 at 7:31
Attachments:
[deleted comment]
Updated source files attached. Binary compatible with previous except that the
'authMethods' provided by the CallbackHandlers now use the
HttpServletRequest.*_AUTH constants, which in some cases aren't the same.
LoginModules should now use the same manifest constants, not string literals.
Fixed a problem with retaining the old username/password after a failed login
attempt.
Original comment by EsmondP...@gmail.com
on 7 Sep 2011 at 7:35
Attachments:
Since Impl only depends on API and not Extras JAASAuthContextImpl can not be in
Impl with JAASAuthContext in Extras. Is there any reason to not put all into
the Extras module?
Also, it would be better to name the classes Jaas*. I know there are different
opinions on this matter all over the place, but a name like
JAASSSLClientAuthenticator is terrible to read.
Original comment by aike.som...@gmail.com
on 13 Sep 2011 at 8:55
1. I don't quite follow the logic here. I would have thought
JAASAuthContextImpl belonged in the Impl package, and I can't see a reason why
not. Certainly the login modules and interfaces can go in Extras ... but then
again as we have discussed I don't see the difference between API and Extras,
or indeed why there are all those Maven packages at all really. I would make
*one* Maven package and two or three Java packages:
name.aikesommer.authenticroast, name.aikesommer.authenticroast.spi (for the
impls), and name.aikesommer.authenticroast.jaas (for the JAAS stuff), and maybe
not even have the last one, just distribute it between the API and the SPI.
2. I don't have a strong view either way about JAAS vs Jaas, but the present
names are hardwired into a couple of webapps so I would need time and space to
change them. If we reconsider the whole namespace as per (1) above we can maybe
get rid of the JAAS prefix altogether. There are a few other items noted on
this issue that should also be brought into the discussion.
Original comment by EsmondP...@gmail.com
on 13 Sep 2011 at 9:46
1. Just try it, the Impl package does not depend on Extras, so anything that a
class in Impl depends on, has to be in API or Impl. Are there any other new
Dependencies, that these classes introduce? If not i would either put them (a)
into API and Impl or (b) into Extras.
2. Okay, then leave it as it is... Can be changed with the more interesting
changes that i have still scheduled for the future!
:-)
Original comment by aike.som...@gmail.com
on 22 Sep 2011 at 7:26
OK so let's say that my stuff goes into Impl and API, basically as per their
names. Maybe we can have a longer-term plan to move Extras into one or the
other.
Original comment by EsmondP...@gmail.com
on 5 Oct 2011 at 7:06
Updated two source files.
(1) Missing synchronization in JAASObjectManager.
(2) JAASAuthContextImpl wasn't <distributable/> because it relied on saving
LoginContexts for logout. This version doesn't do that. The implication of this
change is that LoginModule's logout() methods can no longer rely on any saved
state in their own instances, nor on shared state from the LoginContext, as
both will be new at logout() time. They can only rely on what is in the Subject.
Original comment by EsmondP...@gmail.com
on 21 Nov 2011 at 10:59
Attachments:
Original issue reported on code.google.com by
EsmondP...@gmail.com
on 8 Nov 2010 at 11:47