Return-Path: 
 <dev-return-50956-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 48347 invoked from network); 9 Jun 2007 17:58:04 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 9 Jun 2007 17:58:04 -0000
Received: (qmail 95691 invoked by uid 500); 9 Jun 2007 17:58:06 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 95496 invoked by uid 500); 9 Jun 2007 17:58:05 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@geronimo.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@geronimo.apache.org>
List-Post: <mailto:dev@geronimo.apache.org>
Reply-To: dev@geronimo.apache.org
List-Id: <dev.geronimo.apache.org>
Delivered-To: mailing list dev@geronimo.apache.org
Received: (qmail 95485 invoked by uid 99); 9 Jun 2007 17:58:05 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Jun 2007 10:58:05 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: local policy)
Received: from [69.147.95.77] (HELO smtp114.plus.mail.sp1.yahoo.com)
 (69.147.95.77)
    by apache.org (qpsmtpd/0.29) with SMTP; Sat, 09 Jun 2007 10:58:01 -0700
Received: (qmail 66127 invoked from network); 9 Jun 2007 17:57:40 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer;
  b=x7HV7VUtAlAD3qxuLm2JboLVxcEJ4uEV2ZV7FQPzos7LETziUahMvQ6VqKA97rlKNONHN5v/LpAYoj53wb+Sx1xwKl55+ajqglXEYLMTI+B8YSBBbmig7IPILZBne4T/6gZnTS64DucuAaebDxjVgZSWrO68JW3yDdCjWwPRiT4=
  ;
Received: from unknown (HELO ?10.11.55.8?) (david_jencks@63.105.20.225 with
 plain)
  by smtp114.plus.mail.sp1.yahoo.com with SMTP; 9 Jun 2007 17:57:40 -0000
X-YMail-OSG: 
 b7h6KdYVM1kuYCV0rfu_lPiscPP9qeQw2D9ldzsDN9j5vllc3PNZZqCMFBFjnA4sA9LhWa_NoIzRuNYpay0sjwiYLAUPYNXon6M-
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <1A96204B-3263-4B25-997E-A105F9524929@yahoo.com>
References: <E9F0CE1E-E99E-460E-AB21-2DEAF30F2CAB@yahoo.com>
 <74e15baa0706051716w263941e8q15086f228f3f3fe2@mail.gmail.com>
 <1A96204B-3263-4B25-997E-A105F9524929@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B34A8785-905E-4BBC-9FD6-DC8453865C2C@yahoo.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Proposed Security changes for run-as and default subjects.
Date: Sat, 9 Jun 2007 10:58:15 -0700
To: dev@geronimo.apache.org
X-Mailer: Apple Mail (2.752.3)
X-Virus-Checked: Checked by ClamAV on apache.org

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
>>>
>>>
>>>
>>>
>