Security Model and JAAS

[Dan Diephouse <di...@eastnode.com>]

JAAS:  Jaas is a complex beast, and from what I can tell does not work 
well in the context of Turbine.  I have found a couple resources on it 
and applying it to web applications.  They aren't neccessarily all that 
relavent, but some people might want to see them.

1) javageeks.com did an article on implementing a custom Policy, which 
is a starting point on how to do a custom (database, xml, etc) 
implementation for the policy instead of a filebased policy file.  While 
it isn't directly talking about JAAS it certainly applies.
http://www.javageeks.com/Papers/JavaPolicy/JavaPolicy.pdf

2) On a more random note Struts had a small discussion about it once 
upon a time.
http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg14163.html

Correct me if I'm wrong on my next couple conclusions on why I think a 
JAAS based security is bad:
1) You have to overide the security policy for the whole VM.  This means 
that all your applications under the VM have to follow the JAAS security 
policy.  I don't think you can have multiple security policies for 
different webapps.

2) Not to mention its a huge pain in the arse to implement.  Databases 
are cake, policies are not.  Look at the javageeks.com impelementation.

3) Even if #1 and #2 weren't that bad, not only do we need to implement 
our security policy, but also our policy negates the vm's current 
policy.  So people's policy file is overridden

There is a Policy.setPolicy() method, but I can't figure out if that 
sets the policy for the whole vm, or just for the current thread.  That 
could be an option.  

Now, in light of those observations - I think it would be very cool if 
we could optionally use JAAS for login authentication.  Although I have 
no idea how to begin doing that.  

For more information there is of course the sun website: 
http://java.sun.com/products/jaas/

I am no means an expert, but I thought I'd share my conclusions.

- Dan Diephouse


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Security Model and JAAS

[Santiago Gala <sg...@hisitech.com>]

Dan Diephouse wrote:

> JAAS:  Jaas is a complex beast, and from what I can tell does not work 
> well in the context of Turbine.  I have found a couple resources on it 
> and applying it to web applications.  They aren't neccessarily all 
> that relavent, but some people might want to see them.

It is true, but sometimes (for instance in J2EE environments) you will 
be forced to use it, and it should be already there,

>
> 1) javageeks.com did an article on implementing a custom Policy, which 
> is a starting point on how to do a custom (database, xml, etc) 
> implementation for the policy instead of a filebased policy file.  
> While it isn't directly talking about JAAS it certainly applies.
> http://www.javageeks.com/Papers/JavaPolicy/JavaPolicy.pdf
>
> 2) On a more random note Struts had a small discussion about it once 
> upon a time.
> http://www.mail-archive.com/struts-user%40jakarta.apache.org/msg14163.html 
>
>
> Correct me if I'm wrong on my next couple conclusions on why I think a 
> JAAS based security is bad:
> 1) You have to overide the security policy for the whole VM.  This 
> means that all your applications under the VM have to follow the JAAS 
> security policy.  I don't think you can have multiple security 
> policies for different webapps.

Not always. This situation happens if you are in control of everything 
surrounding you servlet engine. A lot of people is in a situation in 
which J2EE is there, and we already have a policy and/or authentication 
setup. What we want to do now is to have Turbine's system *compatible* 
with it.

What I think would be a reasonable compromise (but maybe other people 
does not think this way) is:

- use java.security.Permission/PermissionCollection classes for the 
implementation of Permissions. (They are relatively independent of the 
rest of the framework, everything is self contained except for the 
checkGuard() method, which checks for the SecurityManager.) Furthermore, 
any java2 implementation loads them, regardless of the SecurityManager 
is active or not.
- implement java.security.Principal in whatever user abstraction we are 
using.
- Leave the service pluggable. (A centralized AccessController which can 
be plugged, with interfaces functionally similar to 
java.security.AccessController)

Then, if a default implementation is done (similar to what we have 
today), it will work similar to what we have today. If anybody needs a 
JAAS implementation, at least the Permission classes are already in 
place (thus the checks in user code are the same, if we wrap 
java.security.AccessController in our 
org.apache.turbine....security.AccessController class)

All classes are there in jdk1.2* (except Subject, that requires JAAS, 
thus jdk1.3+extension or jdk1.4)

>
> 2) Not to mention its a huge pain in the arse to implement.  Databases 
> are cake, policies are not.  Look at the javageeks.com impelementation.

This is not turbine's work. A policy will come in a very near future 
with jdk1.4 (JAAS is there). If this policy implementation is not 
enough, people around Tomcat-land or EJB-land will be the ones to 
implement it. In fact, I think they already have the -security flag to 
start a SecurityManager. We will just configure it and use it. Don't 
forget that J2EE requires this kind of security, and the Servlet API is 
part of J2EE.

Our work is:
- Login the user (this could be done through the Servlet Container, 
using the .getUserPrincipal() in turbine to get this info )
- Setup the

>
> 3) Even if #1 and #2 weren't that bad, not only do we need to 
> implement our security policy, but also our policy negates the vm's 
> current policy.  So people's policy file is overridden
>
> There is a Policy.setPolicy() method, but I can't figure out if that 
> sets the policy for the whole vm, or just for the current thread.  
> That could be an option. 
> Now, in light of those observations - I think it would be very cool if 
> we could optionally use JAAS for login authentication.  Although I 
> have no idea how to begin doing that. 
> For more information there is of course the sun website: 
> http://java.sun.com/products/jaas/

The main obstacle to being able to do this is that our model does not 
cleanly align with java2 security.
If we:
- used java.security.Permission subclasses (extending BasicPermission 
and/or reusing SocketPermission, FIlePermission, etc.)
- implemented java.security.Principal
- had a similar API that what java.security.AccessController has

, in our current implementation, it would be a snap to rewrite our 
AccessController to wrap the java one, and to rewrite the Security 
service Authentication "part" to use JAAS login. The application 
security checks would not need modification.

As an example of this approach, see the Tomcat-4 HEAD cvs source, in 
particular catalina/src/share/org/apache/naming/JndiPermission.java as a 
custom permission, and the Realm classes to see how they allow "classic" 
authentication as well as a toy/prototype JAASRealm.

I'm just trying to have turbine prepare for the future. In my own 
interest, of course. If a Portlet API is standardized I'm quite sure it 
will require the standard java security mechanisms. While current 
Jetspeed can do with a Turbine-2 security implementation, next iteration 
will not, unless it is reasonably easy to write a JAAS compliant 
security service within Turbine.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>