You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2011/08/09 08:53:20 UTC
Ease of use, development & deployment
Following up on recent discussions about security.
Java, River / Jini Security features are advanced programming concepts.
You need security policies, need to know what permissions each codebase requires to function. A key server is essential, along with user Subjects and Principals (including preserving the SubjectDomainCombiner accross privileged calls. Then you've got Proxy trust, verification and dynamic grants.
I've thought previously about having separate releases, one for private networks, the other for untrusted networks. Leading me to consider modularity, to avoid forking, that, classloader issues and codebase annotation loss. But modularity appears to have stalled. A lot of the code I'm writing is in different branches, I'm not great at merging, and will be time poor soon, so I'm concentrating on wrapping up my recent security work.
Does anyone have any suggestions for annotations? So developers can weave in security later, allowing them to get up and running with River in a local network first, then learn security later?
Example: an annotation and the boilerplate code that needs to be weaved in by an annotation processor.
Cheers,
Peter.
Re: Ease of use, development & deployment
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 8/9/2011 7:57 PM, Peter Firmstone wrote:
> Gregg Wonderly wrote:
>> On 8/9/2011 3:56 PM, Greg Trasuk wrote:
>>>
>>> Comments below...
>>>
>>> On Tue, 2011-08-09 at 12:39, Gregg Wonderly wrote:
>>>> I too believe that Authorization is not served well by Subject, at all. The
>>>> reason being that it is not "Role" oriented, but rather "permission" oriented
>>>> and the "permission set" is not always the right "mask" to set in front of a
>>>> decision process, without a lot of permissions that soon become confusing to
>>>> manage without some sort of structured view such as a simple "database" or
>>>> "collection view".
>
> To implement roles in JAAS, you can create a Role implementation like this:
>
> public class Role implements Principal, PrincipalComparator {
> // implementation ...
> }
>
>
> public interface PrincipalComparator {
> boolean implies(Subject subject);
> }
>
> Yeah, I know it's a com.sun interface.
>
> Javadoc from com.sun.security.auth.PrincipalComparator:
>
> /**
> * An object that implements the <code>java.security.Principal</code>
> * interface typically also implements this interface to provide
> * a means for comparing that object to a specified <code>Subject</code>.
> *
> * <p> The comparison is achieved via the <code>implies</code> method.
> * The implementation of the <code>implies</code> method determines
> * whether this object "implies" the specified <code>Subject</code>.
> * One example application of this method may be for
> * a "group" object to imply a particular <code>Subject</code>
> * if that <code>Subject</code> belongs to the group.
> * Another example application of this method would be for
> * "role" object to imply a particular <code>Subject</code>
> * if that <code>Subject</code> is currently acting in that role.
> *
> * <p> Although classes that implement this interface typically
> * also implement the <code>java.security.Principal</code> interface,
> * it is not required. In other words, classes may implement the
> * <code>java.security.Principal</code> interface by itself,
> * the <code>PrincipalComparator</code> interface by itself,
> * or both at the same time.
> *
> * @version 1.17, 05/05/07
> * @see java.security.Principal
> * @see javax.security.auth.Subject
> */
>
>
>
>>>>
>>>> What I did, was create a mechanism that uses "XML" to specify what is needed
>>>> for
>>>> each method in an interface. I've posted about this before, and have not really
>>>> received much feedback either way about it, so I'll hang it out on a stick
>>>> again.
>
> Hang in there, this is difficult terrain and it isn't well understood, people
> don't always digest the info.
>
> I find it's hard to get feedback too, Fred Oliver has been most helpful, so I'm
> hoping he's still following the list.
>
> Many developers would like to ignore security, a benefit of Aspect programming
> is you can weave in security later...
>
>>>>
>>>> Basically, think of these steps as the process.
>>>>
>>>> 1. Design the service interface.
>
> I'm interested, I've been thinking about this too, what's your current service
> interface?
The service interface is "the service interface". The mechanism just uses a
proxy, delegating object. Thus, if you currently have a service object, you
just create an instance of your security object, passing in the service object,
and then export the security object for remote use.
That keeps you from having to support a "single" role model by having that
codified into your application. Instead, the service can be deployed with an
arbitrarily complex authorization implementation making it quite flexible. You
can even use Configuration to specify the security implementation class.
Gregg Wonderly
Re: Ease of use, development & deployment
Posted by Peter Firmstone <ji...@zeus.net.au>.
Since JAAS only provides a framework, ( policy files etc are only
designed for small deployments, they don't scale) I've often wondered if
we should be providing a "default framework".
Apache Shiro is an interesting project, it's probably worth
investigating too.
Cheers,
Peter.
Peter Firmstone wrote:
> Gregg Wonderly wrote:
>> On 8/9/2011 3:56 PM, Greg Trasuk wrote:
>>>
>>> Comments below...
>>>
>>> On Tue, 2011-08-09 at 12:39, Gregg Wonderly wrote:
>>>> I too believe that Authorization is not served well by Subject, at
>>>> all. The
>>>> reason being that it is not "Role" oriented, but rather
>>>> "permission" oriented
>>>> and the "permission set" is not always the right "mask" to set in
>>>> front of a
>>>> decision process, without a lot of permissions that soon become
>>>> confusing to
>>>> manage without some sort of structured view such as a simple
>>>> "database" or
>>>> "collection view".
>
> To implement roles in JAAS, you can create a Role implementation like
> this:
>
> public class Role implements Principal, PrincipalComparator {
> // implementation ...
> }
>
>
> public interface PrincipalComparator {
> boolean implies(Subject subject);
> }
>
> Yeah, I know it's a com.sun interface.
>
> Javadoc from com.sun.security.auth.PrincipalComparator:
>
> /**
> * An object that implements the
> <code>java.security.Principal</code>
> * interface typically also implements this interface to provide
> * a means for comparing that object to a specified
> <code>Subject</code>.
> *
> * <p> The comparison is achieved via the <code>implies</code>
> method.
> * The implementation of the <code>implies</code> method
> determines
> * whether this object "implies" the specified
> <code>Subject</code>.
> * One example application of this method may be for
> * a "group" object to imply a particular <code>Subject</code>
> * if that <code>Subject</code> belongs to the group.
> * Another example application of this method would be for
> * "role" object to imply a particular <code>Subject</code>
> * if that <code>Subject</code> is currently acting in that role.
> *
> * <p> Although classes that implement this interface typically
> * also implement the <code>java.security.Principal</code>
> interface,
> * it is not required. In other words, classes may implement the
> * <code>java.security.Principal</code> interface by itself,
> * the <code>PrincipalComparator</code> interface by itself,
> * or both at the same time.
> *
> * @version 1.17, 05/05/07
> * @see java.security.Principal
> * @see javax.security.auth.Subject
> */
>
>
>
>>>>
>>>> What I did, was create a mechanism that uses "XML" to specify what
>>>> is needed for
>>>> each method in an interface. I've posted about this before, and
>>>> have not really
>>>> received much feedback either way about it, so I'll hang it out on
>>>> a stick again.
>
> Hang in there, this is difficult terrain and it isn't well understood,
> people don't always digest the info.
>
> I find it's hard to get feedback too, Fred Oliver has been most
> helpful, so I'm hoping he's still following the list.
>
> Many developers would like to ignore security, a benefit of Aspect
> programming is you can weave in security later...
>
>>>>
>>>> Basically, think of these steps as the process.
>>>>
>>>> 1. Design the service interface.
>
> I'm interested, I've been thinking about this too, what's your current
> service interface?
>
> Cheers,
>
> Peter.
>
>
>>>> 2. Take each method, and decide what Roles use those methods and
>>>> note the
>>>> roles in a list.
>>>> 3. Decide what types of objects will need to be controlled by role
>>>> based
>>>> access.
>>>> 4. Design permissions that use the values of arguments to the methods
>>>> to segregate access based on role as needed.
>>>
>>> I pretty much agree. You've also added in the idea of role-based
>>> access
>>> to data objects, not just methods, which is cool. If I were going to
>>> implement this, I'd want to make sure we had:
>>>
>>> 1 - A pluggable Subject -> Role and Subject -> Group -> Role mapping
>>> mechanism. You might want database, text file, LDAP, or some other
>>> service-oriented system.
>>
>> I have support for groups. Historically, I've used group names for
>> "role" names with my customers. Then, you just put people into the
>> groups that you want them to participate in the roles thereof.
>>
>>> 2 - Annotation-based config as an alternative to XML. I tend to think
>>> you need XML in case you can't (or don't want to) annotate the original
>>> interfaces or classes, but if you have source access, annotation makes
>>> for a much cleaner configuration. Separate metadata gets tedious after
>>> a while (just ask anyone who's used EJB2).
>>
>> My design was driven completely from the fact that I didn't want
>> "developers" deciding on "authorization design" as part of their
>> development, too much. Keeping authorization on the outside in the
>> form of a "proxied" object, also allows you to "test" without any of
>> that in the mix which simplifies test logic, and allows "pluggable"
>> dummy objects to be used for testing the "authorization" proxy
>> object. It separates the two quite well, but also allows you to
>> doctor up the dummy object with appropriate exception logic to test
>> the client with as well, all locally.
>>
>>> The important thing here, I think, is the observation that JAAS is not
>>> so useful for authorization as it is for authentication.
>>
>> Yes, that is the important thing to me. Subject is interesting, but
>> using the JVMs policy is just too crippling from a number of
>> perspectives.
>>
>> Gregg Wonderly
>>
>
>
Re: Ease of use, development & deployment
Posted by Peter Firmstone <ji...@zeus.net.au>.
Gregg Wonderly wrote:
> On 8/9/2011 3:56 PM, Greg Trasuk wrote:
>>
>> Comments below...
>>
>> On Tue, 2011-08-09 at 12:39, Gregg Wonderly wrote:
>>> I too believe that Authorization is not served well by Subject, at
>>> all. The
>>> reason being that it is not "Role" oriented, but rather "permission"
>>> oriented
>>> and the "permission set" is not always the right "mask" to set in
>>> front of a
>>> decision process, without a lot of permissions that soon become
>>> confusing to
>>> manage without some sort of structured view such as a simple
>>> "database" or
>>> "collection view".
To implement roles in JAAS, you can create a Role implementation like this:
public class Role implements Principal, PrincipalComparator {
// implementation ...
}
public interface PrincipalComparator {
boolean implies(Subject subject);
}
Yeah, I know it's a com.sun interface.
Javadoc from com.sun.security.auth.PrincipalComparator:
/**
* An object that implements the
<code>java.security.Principal</code>
* interface typically also implements this interface to provide
* a means for comparing that object to a specified
<code>Subject</code>.
*
* <p> The comparison is achieved via the <code>implies</code>
method.
* The implementation of the <code>implies</code> method determines
* whether this object "implies" the specified <code>Subject</code>.
* One example application of this method may be for
* a "group" object to imply a particular <code>Subject</code>
* if that <code>Subject</code> belongs to the group.
* Another example application of this method would be for
* "role" object to imply a particular <code>Subject</code>
* if that <code>Subject</code> is currently acting in that role.
*
* <p> Although classes that implement this interface typically
* also implement the <code>java.security.Principal</code>
interface,
* it is not required. In other words, classes may implement the
* <code>java.security.Principal</code> interface by itself,
* the <code>PrincipalComparator</code> interface by itself,
* or both at the same time.
*
* @version 1.17, 05/05/07
* @see java.security.Principal
* @see javax.security.auth.Subject
*/
>>>
>>> What I did, was create a mechanism that uses "XML" to specify what
>>> is needed for
>>> each method in an interface. I've posted about this before, and
>>> have not really
>>> received much feedback either way about it, so I'll hang it out on a
>>> stick again.
Hang in there, this is difficult terrain and it isn't well understood,
people don't always digest the info.
I find it's hard to get feedback too, Fred Oliver has been most helpful,
so I'm hoping he's still following the list.
Many developers would like to ignore security, a benefit of Aspect
programming is you can weave in security later...
>>>
>>> Basically, think of these steps as the process.
>>>
>>> 1. Design the service interface.
I'm interested, I've been thinking about this too, what's your current
service interface?
Cheers,
Peter.
>>> 2. Take each method, and decide what Roles use those methods and
>>> note the
>>> roles in a list.
>>> 3. Decide what types of objects will need to be controlled by role
>>> based
>>> access.
>>> 4. Design permissions that use the values of arguments to the methods
>>> to segregate access based on role as needed.
>>
>> I pretty much agree. You've also added in the idea of role-based access
>> to data objects, not just methods, which is cool. If I were going to
>> implement this, I'd want to make sure we had:
>>
>> 1 - A pluggable Subject -> Role and Subject -> Group -> Role mapping
>> mechanism. You might want database, text file, LDAP, or some other
>> service-oriented system.
>
> I have support for groups. Historically, I've used group names for
> "role" names with my customers. Then, you just put people into the
> groups that you want them to participate in the roles thereof.
>
>> 2 - Annotation-based config as an alternative to XML. I tend to think
>> you need XML in case you can't (or don't want to) annotate the original
>> interfaces or classes, but if you have source access, annotation makes
>> for a much cleaner configuration. Separate metadata gets tedious after
>> a while (just ask anyone who's used EJB2).
>
> My design was driven completely from the fact that I didn't want
> "developers" deciding on "authorization design" as part of their
> development, too much. Keeping authorization on the outside in the
> form of a "proxied" object, also allows you to "test" without any of
> that in the mix which simplifies test logic, and allows "pluggable"
> dummy objects to be used for testing the "authorization" proxy
> object. It separates the two quite well, but also allows you to
> doctor up the dummy object with appropriate exception logic to test
> the client with as well, all locally.
>
>> The important thing here, I think, is the observation that JAAS is not
>> so useful for authorization as it is for authentication.
>
> Yes, that is the important thing to me. Subject is interesting, but
> using the JVMs policy is just too crippling from a number of
> perspectives.
>
> Gregg Wonderly
>
Re: Ease of use, development & deployment
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 8/9/2011 3:56 PM, Greg Trasuk wrote:
>
> Comments below...
>
> On Tue, 2011-08-09 at 12:39, Gregg Wonderly wrote:
>> I too believe that Authorization is not served well by Subject, at all. The
>> reason being that it is not "Role" oriented, but rather "permission" oriented
>> and the "permission set" is not always the right "mask" to set in front of a
>> decision process, without a lot of permissions that soon become confusing to
>> manage without some sort of structured view such as a simple "database" or
>> "collection view".
>>
>> What I did, was create a mechanism that uses "XML" to specify what is needed for
>> each method in an interface. I've posted about this before, and have not really
>> received much feedback either way about it, so I'll hang it out on a stick again.
>>
>> Basically, think of these steps as the process.
>>
>> 1. Design the service interface.
>> 2. Take each method, and decide what Roles use those methods and note the
>> roles in a list.
>> 3. Decide what types of objects will need to be controlled by role based
>> access.
>> 4. Design permissions that use the values of arguments to the methods
>> to segregate access based on role as needed.
>
> I pretty much agree. You've also added in the idea of role-based access
> to data objects, not just methods, which is cool. If I were going to
> implement this, I'd want to make sure we had:
>
> 1 - A pluggable Subject -> Role and Subject -> Group -> Role mapping
> mechanism. You might want database, text file, LDAP, or some other
> service-oriented system.
I have support for groups. Historically, I've used group names for "role" names
with my customers. Then, you just put people into the groups that you want them
to participate in the roles thereof.
> 2 - Annotation-based config as an alternative to XML. I tend to think
> you need XML in case you can't (or don't want to) annotate the original
> interfaces or classes, but if you have source access, annotation makes
> for a much cleaner configuration. Separate metadata gets tedious after
> a while (just ask anyone who's used EJB2).
My design was driven completely from the fact that I didn't want "developers"
deciding on "authorization design" as part of their development, too much.
Keeping authorization on the outside in the form of a "proxied" object, also
allows you to "test" without any of that in the mix which simplifies test logic,
and allows "pluggable" dummy objects to be used for testing the "authorization"
proxy object. It separates the two quite well, but also allows you to doctor up
the dummy object with appropriate exception logic to test the client with as
well, all locally.
> The important thing here, I think, is the observation that JAAS is not
> so useful for authorization as it is for authentication.
Yes, that is the important thing to me. Subject is interesting, but using the
JVMs policy is just too crippling from a number of perspectives.
Gregg Wonderly
Re: Ease of use, development & deployment
Posted by Greg Trasuk <tr...@stratuscom.com>.
Comments below...
On Tue, 2011-08-09 at 12:39, Gregg Wonderly wrote:
> I too believe that Authorization is not served well by Subject, at all. The
> reason being that it is not "Role" oriented, but rather "permission" oriented
> and the "permission set" is not always the right "mask" to set in front of a
> decision process, without a lot of permissions that soon become confusing to
> manage without some sort of structured view such as a simple "database" or
> "collection view".
>
> What I did, was create a mechanism that uses "XML" to specify what is needed for
> each method in an interface. I've posted about this before, and have not really
> received much feedback either way about it, so I'll hang it out on a stick again.
>
> Basically, think of these steps as the process.
>
> 1. Design the service interface.
> 2. Take each method, and decide what Roles use those methods and note the
> roles in a list.
> 3. Decide what types of objects will need to be controlled by role based
> access.
> 4. Design permissions that use the values of arguments to the methods
> to segregate access based on role as needed.
I pretty much agree. You've also added in the idea of role-based access
to data objects, not just methods, which is cool. If I were going to
implement this, I'd want to make sure we had:
1 - A pluggable Subject -> Role and Subject -> Group -> Role mapping
mechanism. You might want database, text file, LDAP, or some other
service-oriented system.
2 - Annotation-based config as an alternative to XML. I tend to think
you need XML in case you can't (or don't want to) annotate the original
interfaces or classes, but if you have source access, annotation makes
for a much cleaner configuration. Separate metadata gets tedious after
a while (just ask anyone who's used EJB2).
The important thing here, I think, is the observation that JAAS is not
so useful for authorization as it is for authentication.
Cheers,
Greg.
Re: Ease of use, development & deployment
Posted by Gregg Wonderly <gr...@wonderly.org>.
I too believe that Authorization is not served well by Subject, at all. The
reason being that it is not "Role" oriented, but rather "permission" oriented
and the "permission set" is not always the right "mask" to set in front of a
decision process, without a lot of permissions that soon become confusing to
manage without some sort of structured view such as a simple "database" or
"collection view".
What I did, was create a mechanism that uses "XML" to specify what is needed for
each method in an interface. I've posted about this before, and have not really
received much feedback either way about it, so I'll hang it out on a stick again.
Basically, think of these steps as the process.
1. Design the service interface.
2. Take each method, and decide what Roles use those methods and note the
roles in a list.
3. Decide what types of objects will need to be controlled by role based
access.
4. Design permissions that use the values of arguments to the methods
to segregate access based on role as needed.
The basics are specified as shown here.
<methodaccess>
<control>
<principals>
<principal type="users" memberof="groups" admin="yes"/>
<principal type="groups" admin="no"/>
</principals>
<object type="director" access="update,read,download"
permission="DirectorAccessPermission"/>
<object type="config" access="update,read"
permission="ConfigAccessPermission"/>
<object type="database" access="update,read"
permission="DatabaseAccessPermission"/>
</control>
...
</methodaccess>
This stuff is all stored and referenced from some backing store, such as a
database, but you can "create" the appropriate backing store through an API.
The above will cause code to be created that will populate the backing store
with the shown items to "initialize" the store.
Here's a method definition for a method that requires "config" role access. The
<limit> entries specify the type="config" attribute that says thats the
role/permission. The access="" attribute says what type of access is required,
and the <create> says that we should create backing store specified entries use
regSet.getName() as the key in the backing store for access to be granted.
Thus, initially, a user would be given administrative access, and through the
application UI, calling this method, would cause the entries to be created that
other users could then be given role based access to by granting them so.
<method return="void" name="setRegSet" qualifiers="public">
<descr>
Security definition for setRegSet() method
</descr>
<security>
<limit access="update" type="config" inst="regSet" arg="regset"
via="arg" method="getName"/>
<create access="update" type="config" inst="regSet"
arg="regset" via="arg" method="getName"/>
</security>
<args>
<arg name="regset" type="com.cytetech.dcm.data.RegSet" descr=""/>
</args>
<exceptions>
<throws name="java.sql.SQLException" descr=""/>
<throws name="java.rmi.RemoteException" descr=""/>
</exceptions>
</method>
There is a complete admin UI panel set that you tie to the backing store, and
the tooling runs across this XML and generates a Java class which you then just
instantiate with an instance of the original class, and then you export this one
instead of the original one. The generated class then completely implements
your authorization scheme, independent of Java Policy, so that authorization is
about application items and not about "java policy".
It's a "big bunch of code", so it's not "simple to use" without some learning.
It's also probably not "perfect" for your needs. But, I've been using various
versions of this code since JDK1.1 and JDK1.3 before JAAS hit the scenes. I
tried desperately to keep JAAS from just being about Java Policy controls, and
to get "Real Authentication" to happen. Alas, it never did. So, I also use JNI
code that I put together to call into PAM on Linux for Subject authentication.
The sheer complexity of this kind of thing is what troubles me the most about
Jini security. It really becomes a giant ordeal to get "right" let alone "made
simple".
Gregg Wonderly
On 8/9/2011 10:58 AM, Greg Trasuk wrote:
>
> On Tue, 2011-08-09 at 02:53, Peter wrote:
>> Following up on recent discussions about security.
>>
>> Java, River / Jini Security features are advanced programming concepts.
>>
>> You need security policies, need to know what permissions each codebase requires to function. A key server is essential, along with user Subjects and Principals (including preserving the SubjectDomainCombiner accross privileged calls. Then you've got Proxy trust, verification and dynamic grants.
>>
>> I've thought previously about having separate releases, one for private networks, the other for untrusted networks. Leading me to consider modularity, to avoid forking, that, classloader issues and codebase annotation loss. But modularity appears to have stalled. A lot of the code I'm writing is in different branches, I'm not great at merging, and will be time poor soon, so I'm concentrating on wrapping up my recent security work.
>>
>
> I don't see separate releases solving anything. The security setup
> should just be a matter of selecting a different Configuration file,
> depending on what level and type of transport security and
> confidentiality you want. I'd picture supplying a minimal-security
> configuration and a maximal-lockdown config for Kerberos and SSL.
>
>
>> Does anyone have any suggestions for annotations? So developers can weave in security later, allowing them to get up and running with River in a local network first, then learn security later?
>>
>
> Some random thoughts:
> - Security can be decomposed into
> - Authentication
> - Authorization
> - Integrity of communications
> - Confidentiality of communications
> - Jeri does a great job with Authentication (can use Kerberos or X509
> certs), Cinfidentiality and Integrity (through SSL, https, Kerberos
> endpoints).
> - The SecurityPolicy model was originally intended to support
> codebase-based security (i.e. permissions are applied to a
> ProtectionDomain associated with the source of the code).
> - JAAS extension glued on Subject-based decisions to the SecurityPolicy
> model after-the-fact.
>
> I've been gradually becoming convinced that the JAAS security model
> (i.e. SubjectDomainCombiner etc) is not very good for subject-based
> authorization. The basic business need for a service is to answer the
> question "Is Bob allowed to place a purchase order?", where Bob's
> authorization might be subject to change over time, or might be subject
> to additional business rules. Seems like in order to enforce that
> decision using the SecurityPolicy model, we end up needing elaborate
> constructs (e.g. revokable permissions, remote policy files,
> classloader/protection domain magic, dynamic policy lookup, etc).
>
> I can't help wondering if the deployer's life is made easier if we just
> say "Authorization is the service's problem" for now. Possibly we could
> design an AuthorizationService that the service implementor could
> delegate to for that decision. At least then, supporting a cached,
> dynamic authorization policy (for service-,ethod-level authorization)
> wouldn't need so much digging around at low levels. The
> DynamicPolicyProvider already allows for assigning limited system
> privileges to a proxy class.
>
> Thoughts?
>
>> Example: an annotation and the boilerplate code that needs to be weaved in by an annotation processor.
>>
> EJB3 includes @RolesAllowed. I wouldn't want to couple to the Java EE
> API, but something similar would work. Then it wouldn't be a major
> trick to create a delegating proxy that checked the required security
> roles.
>
> Alternately, just make the client subject available and the app
> developer could use something like Spring Security to implement the
> method-level authorization. Again I wouldn't want to couple River to
> Spring in any way, but the required liaison classes could be in a
> separate support package.
>
>> Cheers,
>>
>> Peter.
>
>
Re: Ease of use, development & deployment
Posted by Peter Firmstone <ji...@zeus.net.au>.
Greg Trasuk wrote:
> I don't see separate releases solving anything. The security setup
> should just be a matter of selecting a different Configuration file,
> depending on what level and type of transport security and
> confidentiality you want. I'd picture supplying a minimal-security
> configuration and a maximal-lockdown config for Kerberos and SSL.
>
That makes perfect sense, the reason I was considering separation was
more political than functional. Different developers have different
focus points.
>
>
>> Does anyone have any suggestions for annotations? So developers can weave in security later, allowing them to get up and running with River in a local network first, then learn security later?
>>
>>
>
> Some random thoughts:
> - Security can be decomposed into
> - Authentication
> - Authorization
> - Integrity of communications
> - Confidentiality of communications
> - Jeri does a great job with Authentication (can use Kerberos or X509
> certs), Cinfidentiality and Integrity (through SSL, https, Kerberos
> endpoints).
> - The SecurityPolicy model was originally intended to support
> codebase-based security (i.e. permissions are applied to a
> ProtectionDomain associated with the source of the code).
> - JAAS extension glued on Subject-based decisions to the SecurityPolicy
> model after-the-fact.
>
> I've been gradually becoming convinced that the JAAS security model
> (i.e. SubjectDomainCombiner etc) is not very good for subject-based
> authorization. The basic business need for a service is to answer the
> question "Is Bob allowed to place a purchase order?", where Bob's
> authorization might be subject to change over time, or might be subject
> to additional business rules. Seems like in order to enforce that
> decision using the SecurityPolicy model, we end up needing elaborate
> constructs (e.g. revokable permissions, remote policy files,
> classloader/protection domain magic, dynamic policy lookup, etc).
>
Sorry about the lengthy post:
Yes you're right, this is the motivation behind my work, what we need is
something that runs on top of these constructs to make it easy for
application developers.
OSGi has a different security model, that pre-dates the jre, using
conditional permission's, if a condition isn't satisfied, then neither
is the permission, it also delays some permission decisions. Eg in an
embedded device, there might not be a user to ask to grant a
permission. It supports permission addition and removal, it doesn't
prevent security sensitive object references escaping further security
checks, but it is more flexible.
http://www.osgi.org/javadoc/r4v43/org/osgi/service/condpermadmin/ConditionalPermissionAdmin.html
You have to remember that Netscape was competing to implement a browser
based security model at the time, so thing's could have been worse. Li
didn't get to do all the things he wanted, it's still a testament to his
efforts though.
I like to keep a simple picture in my mind when performing security checks.
The jvm maintains the context for each thread, a snapshot of the call
stack, a Subject's principals are injected into the current call stack
with SubjectDomainCombiner, so I like to think of a thread as
representing a user (Subject) and a ProtectionDomain representing the code.
Java security historically had a unique focus on code based security.
Other enterprise software at the time focused on the user. The
DomainCombiner concept is ok, but SubjectDomainCombiner is a bit clunky,
it uses a separate cache for each object, it suffers from creating too
many short lived ProtectionDomain objects (that don't implement equals
or hashCode) causing garbage collection. Different Subject's can often
have identical Principal's, especially if you're a Server with many
clients. It would make sense to have a SubjectDomainCombiner with a
static concurrent cache of ProtectionDomain's. SubjectDomainCombiner is
non final so it could be re implemented, but you couldn't use any of
Subject's static methods. But doing so is probably not worth the added
complication of new api.
I want to close up the proxy unmarshalling DOS attack hole by granting
DownloadPermission to specific Certificate signer's, this answers the
question: "Do I trust the code to unmarshall?" But I don't want to have
to edit every node's policy files and I don't want the policy to be
downloaded from a URL either.
Also I've added a tool com.sun.jini.tool.ProfilingSecurityManager, that
prints out Permissions required for each CodeSource during execution.
These permission's can be either granted to Principal's or CodeSource's.
So I'm now focusing on another tool that allows the developer to include
a list of Permissions a proxy requires to execute locally, in the
proxy's jar file. These can be dynamically granted by the user if
permitted by the administrator (using GrantPermission).
My use for RemotePolicy is; it allows an administrator to dynamically
update permissions for an entire djinn group, where services joining the
group decide if they want to subscribe to that group's policies. Since
the administrator of the group must authenticate, and runs with the
administrator subject, foreign clients participating in the group can
limit the permissions they're prepared to grant to that groups
administrator Subject with GrantPermission. You can't do this with
existing URL based policy files. The administrator is notified of
rejected Policy updates with a SecurityException wrapped in a
RemoteException. The RemotePolicy update either succeeds or fails
completely if a SecurityException occurs. This allows the administrator
to be informed of policy failures and address them.
In the environment I'm interested in deploying, I can't ignore the Code
trust issue.
But concurrency is a problem with existing Policy implementations.
My recent development focus has been to improve the concurrency of
security checks, The concurrent DynamicPolicyProvider at present is
running (20 hours) through all qa tests (recently merged with the
current trunk), it has passed all policy and security tests. The
current focus is on correctness. I've got a new SecurityManager that
caches the results of Permission checks for AccessControlContext, so if
a lot of threads have identical AccessControlContext and are executed
concurrently, then the security check is only performed once. Eg in an
application with 16 threads, an Executor or something like that
performing a computation task for a user, security checks won't be
repeated for every thread, once a check has passed for the context, it
first looks for a successful result from a previous call in the cache
before performing the costly permission check. I have two different
implementations of the SecurityManager at present, this will be narrowed
down to one later. SubjectDomainCombiner is still a performance issue
when the context changes though and you must ensure all threads share
the same Subject and SubjectDomainCombiner, so they utilise identical ==
ProtectionDomains in their context.
All the other work is low level platform stuff.
Revocation and RemotePolicy won't be included in the net.jini namespace
unless they become standardised. I've created the namespace
org.apache.river.api.* as a staging area for new api, to indicate that
it may be moved to net.jini at some point in future. We might decide to
put some of the com.sun namespace there while trying to decide what
should be standardised and whether any changes should be made before we do.
DelegateSecurityManager is an interface that allows a SecurityManager to
provide support for delegate objects, which are designed to encapsulate
existing object's like Socket's and Streams, to allow permission to be
revoked, eg a Principal no longer has access to a resource or a
CodeSource has been found to have a vulnerability. (This isn't just
about removing it from the policy, it's about stopping security
sensitive object references escaping, avoiding further security
checks). Allowing references to escape by only checking guards in
constructors was probably a performance compromise. Delegates use Li
Gong's method guard pattern.
Once a user has a Socket reference (in the code he / she's using) they
can continue using that Socket until they logout (because the security
check is only performed when constructing the Socket). But with a
delegate, as soon as they no longer have the
DelegatePermission(SocketPermission perm), they can no longer utilise
the socket. The delegate object creates a guard in it's constructor,
which is checked on every method call, because the
DelegateSecurityManager uses hash tables to cache permission check
results, the performance impact isn't as great, so long as you have a
sufficient buffer size (not checking every byte). If you're after
ultimate performance, don't use the delegate, if you want to trial trust
and stop attacks in progress, use a delegate. If a
DelegateSecurityManager is not installed, then the delegates don't check
the guard, instead the candidate Permission is checked during
construction of the protected object without using doPrivileged. As far
as the client and user is concerned, it's just an ordinary Socket. I'll
be providing a SocketFactory and ServerSocketFactory, which accept any
other type of SocketFactory's to enable the use of delegates with Sockets.
This allows you to use delegates in your code and decide whether they
should be enabled or not at runtime.
You don't require a policy that supports revocation if you use principal
based grants for DelegatePermissions. Revocation policy support is only
required for codesource based or dynamic grant's for DelegatePermission.
The candidate Permission is the Permission the DelegatePermission
represents. The delegate object's privileged domain must have the
candidate permission, it uses doPrivileged to perform the action on the
user's behalf, the user must have the DelegatePermission or it's
candidate Permission. A candidate Permission is any Permission that
cannot be revoked because it lets a reference to a security sensitive
object to escape. Not all java Permission's let references escape, eg
PropertyPermission's are revocable and don't need delegates.
Since existing Permission's can't be utilised (they let references
escape) the DelegatePermission(Permission perm) constructor allow's it
to represent another Permission, the DelegateSecurityManager when asked
to check a DelegatePermission will also check if a ProtectionDomain has
the candidate Permission. For example this allows you to make a
temporary permission grant like SocketPermission using a delegate
permission, a delegate object checks it's DelegatePermission Guard
object, and doesn't let the Socket escape after the permission check,
instead it encapsulates the Socket and continues to check the
DelegatePermission guard with method invocations. This wouldn't be
possible without a security manager that performs result caching.
Cheers,
Peter.
Re: Ease of use, development & deployment
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Tue, 2011-08-09 at 02:53, Peter wrote:
> Following up on recent discussions about security.
>
> Java, River / Jini Security features are advanced programming concepts.
>
> You need security policies, need to know what permissions each codebase requires to function. A key server is essential, along with user Subjects and Principals (including preserving the SubjectDomainCombiner accross privileged calls. Then you've got Proxy trust, verification and dynamic grants.
>
> I've thought previously about having separate releases, one for private networks, the other for untrusted networks. Leading me to consider modularity, to avoid forking, that, classloader issues and codebase annotation loss. But modularity appears to have stalled. A lot of the code I'm writing is in different branches, I'm not great at merging, and will be time poor soon, so I'm concentrating on wrapping up my recent security work.
>
I don't see separate releases solving anything. The security setup
should just be a matter of selecting a different Configuration file,
depending on what level and type of transport security and
confidentiality you want. I'd picture supplying a minimal-security
configuration and a maximal-lockdown config for Kerberos and SSL.
> Does anyone have any suggestions for annotations? So developers can weave in security later, allowing them to get up and running with River in a local network first, then learn security later?
>
Some random thoughts:
- Security can be decomposed into
- Authentication
- Authorization
- Integrity of communications
- Confidentiality of communications
- Jeri does a great job with Authentication (can use Kerberos or X509
certs), Cinfidentiality and Integrity (through SSL, https, Kerberos
endpoints).
- The SecurityPolicy model was originally intended to support
codebase-based security (i.e. permissions are applied to a
ProtectionDomain associated with the source of the code).
- JAAS extension glued on Subject-based decisions to the SecurityPolicy
model after-the-fact.
I've been gradually becoming convinced that the JAAS security model
(i.e. SubjectDomainCombiner etc) is not very good for subject-based
authorization. The basic business need for a service is to answer the
question "Is Bob allowed to place a purchase order?", where Bob's
authorization might be subject to change over time, or might be subject
to additional business rules. Seems like in order to enforce that
decision using the SecurityPolicy model, we end up needing elaborate
constructs (e.g. revokable permissions, remote policy files,
classloader/protection domain magic, dynamic policy lookup, etc).
I can't help wondering if the deployer's life is made easier if we just
say "Authorization is the service's problem" for now. Possibly we could
design an AuthorizationService that the service implementor could
delegate to for that decision. At least then, supporting a cached,
dynamic authorization policy (for service-,ethod-level authorization)
wouldn't need so much digging around at low levels. The
DynamicPolicyProvider already allows for assigning limited system
privileges to a proxy class.
Thoughts?
> Example: an annotation and the boilerplate code that needs to be weaved in by an annotation processor.
>
EJB3 includes @RolesAllowed. I wouldn't want to couple to the Java EE
API, but something similar would work. Then it wouldn't be a major
trick to create a delegating proxy that checked the required security
roles.
Alternately, just make the client subject available and the app
developer could use something like Spring Security to implement the
method-level authorization. Again I wouldn't want to couple River to
Spring in any way, but the required liaison classes could be in a
separate support package.
> Cheers,
>
> Peter.