Jaas -- A conceptual Question..
Hi.. I'm in the process of developing a JSF application that will make use of JAAS. I'm trying to dig through the myraid of information out there to makes sense of things and now i find myself asking a simple question to make things clearer..
Can we use the typical JAAS approach for authentication in Web applications. By typical i mean (creating a LoginContext, specifying a config file and passing an optional callback handler to the loging context, specifying the login url in the java.security file and giving permissions in java.policy files).
From what I have understood, the procedure is different for web apps. Each app server has its own implementations for JAAS that one can use. Or if there are any other needs, one can write their own loginmodules according to the app server spec. You declare that as the realm to use in your deployment descriptor file. Thus in this scenario you would not be creating a login context etc and the container is handling everying for you.. i.e. its an example of declarative authentication using a particular realm..
I would really appreciate if someone can comment on this and if i'm going in the right direction...
THANKS
Hello there,
If your app-server follows the J2EE specification then you need not concern yourself with different implementations - they will all give uniform behaviour.
I know that web-servers permit basic (dialog) and form based authentication, and use its own CallbackHandler. You implement a LoginModule as your role as an authentication provider in the PAM paradigm. I know Tomcat for example has some additional guidelines to help it distinguish between user-principals and role-principals, but this does not violate the specification.
What is your app-server? Find the documentation and search through it to determine how it handles/offers JAAS authentication.
You could totally bypass all the container manged authetication and just code it directly in your app. you will also need to determine if your app-server uses the default policy/config files or whether there is somewhere in its configuration where you need to specify these files' locations.
Good luck,
Darren
hi,
"You could totally bypass all the container manged authetication and just code it directly in your app."
=> it's not a good security design.
all the security must be controlled by the sevrer administrator outside the container.
but, the administrator can and should delegate authorizations to the webapp (not authentication).
so, to use JAAS in a J2EE environment in an easy way, i think you should look towards the jguard project (http://jguard.sourceforge.net) which wrap the jaas complexity for you, and enable flexibility (for example, you can change role <-> permissions on the fly) .
and many others features....
hope it helps,
Charles(jguard team).
Yeah, listen to the guy pluggin' his own interests.
There are some off us that have an interest in how things work - perhaps I speak for myself, perhaps not.
We have actually crossed paths before, when you told me to look at JGuard despite me stating my system was/is a client-server application i.e. not a web-app.
I'm being objective and offering options.
Hi Guys,
Thanks for you reply.
I'm using Sun's AppServer 8.1. SO here is my story.. initially I started out implementing a callbackhandler, and passing the username and password to my loginmodule. I created the config file called jaas.config which had auth information like
jaasApp{
JNDILoginModule required;
};
I however enconuntered a SecurityException as I didnt have the permission to create a logincontext. Fine --this indicates i need to have proper permissions in my server.policy files.
My problem at that point was however how do i let the server know that use this jaas.config file that i've created for authentication information. when i tried to specify the location of this config file in $java_home/jre/lib/security/java.security file, (as u are supposed to in order to indicate the login.config.url.1) but my appserver wouldn't start and indicated problems.
THEREFORE i decided i need to do everything declaratively, implement a login module and a realm that is appserver specific (in Sun's Appserver we cannot directly extend LoginModule class but a class which is something like com.sun.enterprise...PassworldLoginModule and also a Realm class that will hook on to the appserver). For reference to the appserver documentation:
http://docs.sun.com/source/819-0079/dgsecure.html#wp22266
Thus now everything becomes declarative....it works fine, i can create my own rdbmLoginModule if i want by extending whatever claases appserver requires me to do, specify that as the realm to use in my web.xml ..authentication works..
So now i was back at square one coz from what it seems like i could use the first approach also. I CAN infact do everything progrmmatically i.e. i need to figure out how to configure the appserver for that..and i can make use of some of the login modules provided in the jdk such as the JNDILoginMOdule, NTLoginModule etc.
I'm SO writing an article after i'm done implmenting to help people out there!
Thanks for your feedback plus i have looked at JGuard, at the moment I need to do this by myself as Darren said i need to learn t his technology so i would like to iimplement it bymyself at the moment..
Thanks for the feedback and look forward to more discussion..
Hello RR,
I do not know the specification for JAAS in a J2EE based system but asyou later discovered not being able to extend LoginModule does not sound right; this is the one real responsibilty imposed on you in the PAM paradigm.
The thing is, because app-servers add an extra layer of... grey cloud (not really, but you know what I mean) between you application logic and the entities that want to use it, they will provide 'pass-through' (not a real term, just descriptive) code, such as a CallbackHandler, that will relay input data in a fashion you have no control over.
Firstly, JNDILoginModule is not the correct nor full class name, com.sun.security.auth.module.JndiLoginModule.
There are many permissions your 'trusted' code will need to work properly wihtin a sandbox. In my opinion it is easy to grant your code ALLPermission, and then lock it down for Subject based actions. Maybe this approach is not compatible with J2EE - I couldn't say.
There must be a place where you can specify system properties, if not as an environment variable. Check the documentation for your app-server. Also be sure of which JDK/JRE the app-server is using (perhaps its own) and hence which java.security file you should be setting.
Funnily enough, I'm having trouble getting Tomcat to use JAAS... it is a royal pain in the ***.
Anyway, good luck,
Darren
Hello again,
Firstly let me apologise for stupid comments like 'find you documentation and...' when you've actually posted a link to it, but most of all, apologies for not taking the time to understand what's going on - J2EE seems to be very different.
I glanced over the link you provided; what a mess! I think there are some blatant typos (or a poor use of cut'n'past, ha ha). 'Custom realms must extend the com.sun.appserv.security.AppservPasswordLoginModule class...' and 'Custom realms must also implement a Realm class which extends the com.sun.appserv.security.AbstractRealm class...' - is this a mistake or does it (superfluosly) state these two class must both be your class' (ancestor) super-classes? I'm inclined to think it is 'multiple-inheritance' Java contradiction if it isn't a typo; somewhere there is a shameful disregard for the difference in semantics of a class and an interface or a Realm and a LoginModule. Wjatever the weather, It would seem JAAS has been shoe-horned into J2EE containers, where JACC is the advocated approach - correct me if this is wrong?It seems for this reason it may not be possible to use the standard J2SE LoginModules - what a shame ay?
I read the section on ProgrammaticLogin; it's existence as provided functionality would suggest that it is NOT such a bad security design. To add, the issues raised under the Precautions sub-heading are trivial to someone who knows how to implement security in a normal application e.g. a normal deployment of JAAS.
Nevertheless, this advocated process for programmatic login still imposes authentication restrictions on the developer - perhaps you've misinterpreted the freedoms it gives you; it's upto you to get the users credentials, but the authentication is still delegated to the container; you can still implement your own Realm/LoginModule (the distinction between the two in this specific context is annoyingly unclear - to explain my earlier comments), but this does not afford you the liberty to use JndiLoginModule or NTLoginModule in the intended way - I wonder, perhaps you could delegate to instances of these classes internally? Anyway, to use this process I think only requires you to grant the ProgrammaticLoginPermission in your server.policy.
As for permissions, they play a very small role in this web-service paradigm where business logic security is largely 'what can you do... what can't you do' action-based. Consequently this is easily accomodated by role-based rights, that is, if you are in a role/group you can do such-and-such, if you're not, you can't. This removes the conventional need for permissions, especially considering Java permissions generally target system-resources and not application-resources. Perhaps it may be worth using roles exactly where permissions would be used, where the role name itself specifies a permitted action?
As for me, turns out I'm my own worst enemy: I specified the wrong path to the config file and through a mix up with Eclipse, the JAR placed in common/lib contained the wrong classes (well, two were missing actually). So now it works fine - except (excuse the pun) the exception that is thrown prior to a first authentication attempt i.e. when the restricted resource is first requested - no big deal I guess. Anyway, I discovered the problems through checking the server logs - I swear blind there were no exceptions in it before, but that will not be the last oversight I make.
Good luck and best regards,
Darren
ps. with out meaning to sound 'I'm great' feel free to use my comments in the article you write - if you feel they are a worthy contribution.
