geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Proposed Security changes for run-as and default subjects.
Date Sat, 09 Jun 2007 17:58:15 GMT
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 <david_jencks@yahoo.com> 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
>>>
>>>
>>>
>>>
>


Mime
View raw message