Re: Proposed Security changes for run-as and default subjects.

Sat, 09 Jun 2007 10:58:02 -0700

I've committed this work in rev 545781. It's a fairly large change so I expect that despite my testing there will be problems. Please speak up if you find some. 

thanks
david jencks

On Jun 6, 2007, at 1:07 AM, David Jencks wrote:



On Jun 5, 2007, at 5:16 PM, Aaron Mulder wrote:


I don't really care about run-as; my main concern is the default
subject/principal.  I think it should be as simple as possible to
create a default subject named "anonymous" with no roles or special
treatment whatsoever (just so if you call things like
getCurrentPrincipal().getName() you don't get an NPE if the user
hadn't logged in yet -- not to allow anonymous users access to any
protected resources).

It looks like the new syntax would be a little worse than "as simple
as possible" if you have to define a CredentialStore in order to
achieve this.  Is there some way we can super-optimize the syntax to
create a user with an application-specific name but no password or
roles or anything?  Perhaps by providing some way to indicate in the
<default-subject> that it should itself create an empty user with the
specified name and realm and no other properties or data (rather than
actually requiring a CredentialStore to be defined)...?
What my implementation does now when you don't specify a default subject, is use a Subject instance with no principals (or credentials) in it. Dain found that the ejb spec requires that getCallerPrincipal can never return null, so if there isn't one it returns a new UnauthenticatedPrincipal. If there's a similar requirement for servlets maybe we should do the same thing?
Do you see problems with just using an empty subject if nothing's specified explicitly? I'm a bit inclined to not put any principals in this default subject, because if you do put one in, someone could map it to some permissions, which defeats some of the purpose. 

thanks
david jencks



Thanks,
    Aaron

On 6/5/07, David Jencks <[EMAIL PROTECTED]> wrote:

I've discussed this at least once before, see also GERONIMO-2687.

I've been working on this idea of having all run-as and default
subjects be from login modules/configurations rather than the current 
plan of constructing subjects from confusing xml.  It seems to be
working pretty well and I'm at the point where I would like to commit 
it so I'd like to find out if there are any objections to the non-
backward-compatible aspects of the changes.

The core of the idea is an interface

public interface CredentialStore {
Subject getSubject(String realm, String id) throws LoginException; 
}

that lets the servlet and ejb containers obtain a subject given an
identifier.
The CredentialStore I've implemented is currently configured with xml 
like this:

     <gbean name="CredentialStore"
class="org.apache.geronimo.security.credentialstore.SimpleCredential Stor 
eImpl">
         <xml-attribute name="credentialStore">
<credential-store xmlns="http://geronimo.apache.org/ xml/ 
ns/credentialstore-1.0">
                 <realm name="my-realm">
                     <subject>
                         <id>foo-run-as</id>
                         <credential>
<type>org.apache.geronimo.security.credentialstore.NameCallbackHandl er</ 
type>
                             <value>foo</value>
                         </credential>
                         <credential>
<type>org.apache.geronimo.security.credentialstore.PasswordCallbackH andl 
er</type>
                             <value>fooPassword</value>
                         </credential>
                     </subject>
                     <subject>
                         <id>bar-run-as</id>
                         <credential>
<type>org.apache.geronimo.security.credentialstore.NameCallbackHandl er</ 
type>
                             <value>bar</value>
                         </credential>
                         <credential>
<type>org.apache.geronimo.security.credentialstore.PasswordCallbackH andl 
er</type>
                             <value>barPassword</value>
                         </credential>
                     </subject>
                 </realm>
             </credential-store>
         </xml-attribute>
     </gbean>


Note that this has cleartext passwords in it.  It's a plan so after
deployment there's no textual representation of it in the car file.
This is obviously a poor feature and I'd certainly like suggestions
for improvement.  One possibility is to put the configuration in a
file which can then be encrypted.  However, it's difficult for me to
figure out a solution that's really secure rather than just obfuscation. 

The plan xml security configuration element now looks like this:

       <security use-context-handler="false">
         <default-subject>
             <realm>my-realm</realm>
             <id>bar-run-as</id>
         </default-subject>
         <role-mappings>
           <role role-name="Administrator">
             <realm realm-name="my-realm">
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="bar"/>
             </realm>
           </role>
           <role role-name="Manager">
             <subject-info>
                 <realm>my-realm</realm>
                 <id>foo-run-as</id>
            </subject-info>
             <realm realm-name="my-realm">
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="foo"/>
             </realm>
           </role>
         </role-mappings>
       </security>

This sets the default subject to bar and the run-as subject for the
Manager role to foo.


--------------------------
Comparison with current model/xml.

Currently there is nothing like the credential store configuration
and the run-as subjects are constructed from xml like this:

       <security use-context-handler="false">
         <default-principal realm-name="cts-properties-realm">
           <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="j2ee"/>
         </default-principal>
         <role-mappings>
           <role role-name="Administrator">
             <realm realm-name="my-realm">
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="bar"/>
             </realm>
           </role>
           <role role-name="Manager">
             <realm realm-name="my-realm">
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="foo" designated-run-as="true"/>
             </realm>
           </role>
         </role-mappings>
       </security>

This is somewhat limiting and I've always found it almost impossible
to understand:
Since all authorization flows from a Subject not a Principal, the
concept of default-principal is kind of ridiculous on its face.
Replacing it with a default subject allows you to configure the
default authorization with whatever detail you want.
Along with the odd practice of constructing a Subject  without using
a login module, this style of configuration can be a bit confusing.
Consider this configuration example:
       <security use-context-handler="false">
         <role-mappings>
           <role role-name="Administrator">
             <realm realm-name="my-realm">
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="bar" designated-run-as="true"/>
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="foo"/>
             </realm>
           </role>
           <role role-name="Manager">
             <realm realm-name="my-realm">
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l" name="foo" designated-run-as="true"/>
             </realm>
           </role>
         </role-mappings>
       </security>

One of the effects of this configuration is that run-as="Manager"
also gets the "Administrator" role, whereas run-as="Administrator"
only gets the "Administrator" role.  I find this very hard to
interpret correctly in practice.  The same kind of effect can occur
in the configuration I'm proposing, but I think it will be a lot more 
obvious: you are picking a particular user in a particular login
realm and it's pretty clear that to find out what roles/permissions
that user has you have to look at all the principals involved and
trace them into the principals>>role>> permission mapping.

------------------------
Backward compatibility state:

I don't see any reasonable way to convert the previous configuration
to work exactly the same way with the new model.  At the moment I've
set up the xml plan processing to delete/ignore default-principal and 
designated-run-as elements/attributes, but not try to reinterpret
them to something in the new system.  So you should still be able to
deploy with an old plan, but the default identity and run as aspects
won't work as expected.

------------------------
Next steps:

-- figure out how to at least obfuscate the credentials in the
credential store configuration
-- figure out how to dynamically manage the contents of the
credential store
-- Our principal>> role mapping is extremely flexible but may often
be waaaaay more complicated than necessary.  Furthermore it's just
possible that some people will want to have run-as-role mean exactly
what it seems, without any other further configuration or
flexibility.  Both these concerns could be addressed by making it
possible to have a principal name == role name mapping.

One possible configuration might look like this:
         <role-mappings>
           <auto-map>
             <realm realm-name="my-realm">
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoGroupPri ncip 
al"/>
               <principal
class="org.apache.geronimo.security.realm.providers.GeronimoUserPrin cipa 
l"/>
             </realm>
             <run-as-realm>run-as-realm</run-as-realm>
           </auto-map>
         </role-mappings>

The <realm> element contains principals for which you want a
principal-name = role-name mapping.
The run-as-realm would set up a realm that requires no credentials,
just a (role) name and produce a subject with a single (role)
principal mapped to that role.
-- I don't think that including the realm in subject-info is strictly 
necessary but at this point I think it will lead to less confusion
and possible overlap, so I'm inclined to keep it. If anyone strongly 
objects it's not hard to remove.


-------------------------------
Please comment. Since this is a backward-incompatible change I would 
like to get it in quickly and definitely before 2.0 goes out the
door.  I'm hoping that few enough people have ever used run-as that
it won't be a major burden on existing users.

thanks
david jencks

Reply via email to