search

ratcashdev / authenticroast

Automatically exported from code.google.com/p/authenticroast
1 stars 0 forks source link

Need access to the JAAS realm #6

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Authenticators need a way to access the current JAAS realm.

Original issue reported on code.google.com by EsmondP...@gmail.com on 8 Nov 2010 at 11:47

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Please see attached draft API for comment.

Original comment by EsmondP...@gmail.com on 12 Nov 2010 at 3:59

Attachments:

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
Logging bug in this, reattached.

Original comment by EsmondP...@gmail.com on 7 Dec 2010 at 7:31

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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: