Re: Geronimo role security

Thu, 19 Jul 2007 09:24:41 -0700 


On Jul 19, 2007, at 9:06 AM, Aman Nanner/MxI Technologies wrote:


The fake EAR did start ok.
I can try deploying the realm as a plain GBean plan, but I'm not sure how to go about doing this as I've only been deploying J2EE modules to this point (EAR, WAR, etc.). Is there some good documentation on how to deploy 
a plain GBean to the 2.0 server according to a plan file?
What ought to work, although I haven't checked it in a very very long time is... 

1. copy the dependency jars into appropriate places in the geronimo repo
2a. deploy using the command line deployer just listing the plan
or
2b. deploy using the console only filling in the plan box

If either one of these doesn't work we should fix it before 2.0 IMO.

thanks
david jencks



Thanks,
Aman



David Jencks <[EMAIL PROTECTED]> wrote on 07-18-2007 05:00:23 PM:


it should be able to, but maybe I'm missing something.  The "fake"
ear started ok?

I was thinking you could just deploy a plain gbean plan with
dependencies on the jars that have the security classes, similar to
the built in server-security-config.

If you can get on IRC we might be able to make faster progress,
although email is fine if you can't.

thanks
david jencks


On Jul 18, 2007, at 1:43 PM, Aman Nanner/MxI Technologies wrote:


I declared the security realm in a separate EAR, and then put a
dependency
on that EAR from my real EAR, but it didn't solve the problem.  In
fact,
the realm lookup failed both the first time and the second time
(instead of
succeeding the second time).  Can an EAR access a Realm declared
within
another EAR when the first EAR is dependent upon the second EAR?
David Jencks <[EMAIL PROTECTED]> wrote on 07-18-2007 04:08:09 PM: 


Urrk, I'm trying to do too many things at once today :-(
Could you try putting the security realm in a separate configuration 
and putting that in as a dependency for the ear?  If we can see if
that eliminates the hiccup and whether that helps find the run-as
subject it would be very helpful

then we'll know how many problems there are to solve :-)

thanks
david jencks

On Jul 18, 2007, at 12:30 PM, Aman Nanner/MxI Technologies wrote:
I tried out the solution, but I'm still having problems in that the 
JSP is
not running under the desired "run-as" role.  I cannot see in the
TomcatGeronimoRealm where this "run-as" role is being set, or if
it is
accessing the credential store to get the run-as subject.

The actual configuration of the credential store seemed to work
fine,
except for one hiccup.
I am deploying a custom security realm as part of my EAR that I call 
"TestingRealm".  It seems that the getSubject(...) method on the
CredentialStore GBean is called twice.  The first time it is
called, fails
because the LoginModule for my custom realm is not "registered".
The
second time the getSubject(...) method is called, the login succeeds 
because my LoginModule IS registered at this time.

This is the stack trace the first time when the call fails:
14:29:13,782 ERROR [GBeanInstanceState] Error while starting; GBean 
is now
in the FAILED state:
abstractName="Mxi/Testing/1/ear?J2EEApplication=Mxi/Testing/1/
ear,j2eeType=JACCManager,name=JACCManager"
javax.security.auth.login.LoginException: No LoginModules
configured for
TestingRealm
      at javax.security.auth.login.LoginContext.init
(LoginContext.java:256)
      at
javax.security.auth.login.LoginContext.<init>(LoginContext.java: 367) 
      at
javax.security.auth.login.LoginContext.<init>(LoginContext.java: 444) 
      at
org.apache.geronimo.security.credentialstore.SimpleCredentialStore Im 
pl
.getSubject(SimpleCredentialStoreImpl.java:82)
      at
org.apache.geronimo.security.credentialstore.SimpleCredentialStore Im 
pl
$$FastClassByCGLIB$$ebe13f46.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java: 53) 
      at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke
(FastMethodInvoker.java:38)
      at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke
(GBeanOperation.java:127)
      at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke
(GBeanInstance.java:830)
      at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java: 
57)
      at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke
(RawOperationInvoker.java:35)
      at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept
(ProxyMethodInterceptor.java:96)
      at
org.apache.geronimo.security.credentialstore.CredentialStore$
$EnhancerByCGLIB$$c06097c7.getSubject(<generated>)
      at
org.apache.geronimo.security.jacc.ApplicationPolicyConfigurationMa na 
ge
r.<init>(ApplicationPolicyConfigurationManager.java:121)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native
Method)
      at
sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
      at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance (Constructor.java: 
494)
      at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance
(GBeanInstance.java:946)
      at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullSt ar 
t(
GBeanInstanceState.java:268)
      at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
(GBeanInstanceState.java:102)
      at
org.apache.geronimo.gbean.runtime.GBeanInstance.start
(GBeanInstance.java:539)
      at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart
(GBeanDependency.java:111)
      at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget
(GBeanDependency.java:146)
      at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running
(GBeanDependency.java:120)
      at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunning Ev 
en
t(BasicLifecycleMonitor.java:176)
      at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300
(BasicLifecycleMonitor.java:44)
      at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor
$RawLifecycleBroadcaster.fireRunningEvent
(BasicLifecycleMonitor.java:254)
      at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullSt ar 
t(
GBeanInstanceState.java:294)
      at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
(GBeanInstanceState.java:102)
      at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursiv e 
(GBeanInstanceState.java:124)
      at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive
(GBeanInstance.java:553)
      at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean
(BasicKernel.java:379)
      at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigura ti 
on
GBeans(ConfigurationUtil.java:448)
      at
org.apache.geronimo.kernel.config.KernelConfigurationManager.start
(KernelConfigurationManager.java:187)
      at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.start Co 
nf
iguration(SimpleConfigurationManager.java:530)
               ......


The call succeeds the second time.  It seems that the
ApplicationPolicyConfigurationManager GBean is started twice which
results
in the two calls?
Below is the fragment of my geronimo-application.xml where I define 
the
security policy:

----------
   <security:security>
         <security:credential-store>
             <security:pattern>
                 <sys:name
xmlns="http://geronimo.apache.org/xml/ns/
deployment-1.2">MyCredentialStore</sys:name>
             </security:pattern>
         </security:credential-store>
      <security:role-mappings>
         <security:role role-name="TESTSYSTEM">
            <security:run-as-subject>
             <security:realm>TestingRealm</security:realm>
             <security:id>test-system</security:id>
            </security:run-as-subject>
            <security:realm realm-name="TestingRealm">
               <security:principal
class="org.apache.geronimo.security.realm.providers.GeronimoGroupP ri 
nc
ipal"
name="TESTSYSTEM" />
            </security:realm>
         </security:role>
      </security:role-mappings>
   </security:security>
   <sys:gbean name="TestingRealm"
class="org.apache.geronimo.security.realm.GenericSecurityRealm">
      <sys:attribute name="realmName">TestingRealm</sys:attribute>
      <sys:reference name="ServerInfo">
         <sys:name>ServerInfo</sys:name>
      </sys:reference>
      <sys:xml-reference name="LoginModuleConfiguration">
         <log:login-config
xmlns:log="http://geronimo.apache.org/xml/ns/loginconfig-2.0";>
            <log:login-module control-flag="REQUIRED"
wrap-principals="false">
               <log:login-domain-name>TestingRealm</log:login-
domain-name>

<log:login-module-class>com.testing.security.TestingLoginModule</
log:login-module-class>
               <log:option name="userSelect">SELECT username,
password FROM
utl_user WHERE username=?</log:option>
               <log:option
name="dataSourceApplication">Mxi/Testing/1/ear</log:option>
               <log:option name="groupSelect">SELECT name,
'TESTSYSTEM' as
role_name FROM dual</log:option>
               <log:option
name="dataSourceName">com/testing/jdbc/TestDS</log:option>
            </log:login-module>
         </log:login-config>
      </sys:xml-reference>
   </sys:gbean>
   <sys:gbean name="MyCredentialStore"
class="org.apache.geronimo.security.credentialstore.SimpleCredenti al 
St
oreImpl">
      <xml-attribute name="credentialStore">
         <credential-store
xmlns="http://geronimo.apache.org/xml/ns/credentialstore-1.0";>
            <!-- uncomment this and the default subject in the

jettty> console plan gives you admin console permissions -->

            <realm name="TestingRealm">
               <subject>
                   <id>test-system</id>
                   <credential>
<type>org.apache.geronimo.security.credentialstore.NameCallbackHan dl 
er
</type>
                      <value>ananner</value>
                   </credential>
                   <credential>
<type>org.apache.geronimo.security.credentialstore.PasswordCallbac kH 
an
dler</type>
                      <value>password</value>
                   </credential>
               </subject>
            </realm>
         </credential-store>
      </xml-attribute>
   </sys:gbean>
----------



David Jencks <[EMAIL PROTECTED]> wrote on 07-18-2007
03:57:36 AM:


run-as handling is completely different in 2.0.  Instead of
constructing a subject out of xml, the run-as subject comes from
logging into a login module just like any other subject.  You
have to
do several things:

-- set up a security realm so the desired subject can in fact be
created by logging in as someone
-- set up a gbean that describes how to login as this subject,
such as

     <gbean name="CredentialStore"
class="org.apache.geronimo.security.credentialstore.SimpleCredent ia 
lS
tor
eImpl">
         <xml-attribute name="credentialStore">
             <credential-store xmlns="http://geronimo.apache.org/
xml/
ns/credentialstore-1.0">
                 <!-- uncomment this and the default subject in

the>> jettty console plan gives you admin console permissions -->

                 <realm name="geronimo-admin">
                     <subject>
                         <id>default</id>
                         <credential>
<type>org.apache.geronimo.security.credentialstore.NameCallbackHa nd 
le
r</
type>
                             <value>system</value>
                         </credential>
                         <credential>
<type>org.apache.geronimo.security.credentialstore.PasswordCallba ck 
Ha
ndl
er</type>
                             <value>manager</value>
                         </credential>
                     </subject>
                 </realm>
             </credential-store>
         </xml-attribute>
     </gbean>

Note that you have to supply the password here.  You can
override the
existing CredentialStore gbean in server-security-config in
config.xml or create your own, perhaps in the geronimo plan for
your
app.

-- in the geronimo security configuration for the role, indicate
the
run-as subject (and default subject if you want one) by its
realm and
id as indicated in the CredentialStore gbean:

     <security>
         <credential-store>
             <pattern>
                 <name xmlns="http://geronimo.apache.org/xml/ns/
deployment-1.2">MyCredentialStore</name>
             </pattern>
         </credential-store>
         <!--<default-subject>-->
             <!--<realm>geronimo-admin</realm>-->
             <!--<id>default</id>-->
         <!--</default-subject>-->
         <role-mappings>
             <role role-name="admin">
                 <run-as-subject>
                     <realm>geronimo-admin</realm>
                     <id>default</id>
                 </run-as-subject>
                 <realm realm-name="geronimo-admin">
                     <principal
class="org.apache.geronimo.security.realm.providers.GeronimoGroup Pr 
in
cip
al" name="admin"/>
                 </realm>
             </role>
         </role-mappings>
     </security>
I think that other than myself you are the first person to try this 
out so your comments would be definitely appreciated.

See also https://issues.apache.org/jira/browse/GERONIMO-2687

thanks
david jencks

On Jul 17, 2007, at 8:15 PM, Aman Nanner/MxI Technologies wrote:
It would appear that the TomcatGeronimoRealm.hasResourcePermission 
(...)
method does not apply the <run-as> role if one is defined.  If
this
indeed
the case, then I believe this is a bug....

Aman Nanner/MxI Technologies <[EMAIL PROTECTED]> wrote on
07-17-2007
10:55:23 PM:



Hi,
I'm using the latest Geronimo 2.0 snapshot from the codebase. I 
understand

that security has changed somewhat from Geronimo 1.2.  I'm
running
into

an
issue where I have a JSP with a specific "run-as" role calling a 
secured
EJB.  This JSP has its run-as role defined in the web.xml as
follows:

----
   <servlet>
      <servlet-name>MessagePage</servlet-name>
      <jsp-file>/common/Message.jsp</jsp-file>
      <run-as>
         <role-name>TESTSYSTEM</role-name>
      </run-as>
   </servlet>
----


 I have a default run-as role mapped in my geronimo-
application.xml in my
EAR as follows:

----
   <security:security>
      <security:default-principal>
         <security:principal
class="org.apache.geronimo.security.realm.providers.GeronimoUser Pr 
in
ci
pal"

name="" />
      </security:default-principal>
      <security:role-mappings>
         <security:role role-name="TESTSYSTEM">
            <security:principal
class="org.apache.geronimo.security.realm.providers.GeronimoUser Pr 
in
ci
pal"

name="test-system" designated-run-as="true" />
         </security:role>
      </security:role-mappings>
   </security:security>
----

This used to work in Geronimo 1.2, but it appears now that the
JSP
does

not

run with the run-as principal; rather it seems that it runs
with no
principals.  Therefore, the call to the secured EJB causes a
security
access exception.  Is this supposed to work the same way in
Geronimo 2.0?
If so, then maybe this is a problem in Tomcat ....

Thanks,
Aman
________________________________________________________________ __ 
__
__
____________
* This message is intended only for the use of the individual or 
entity to which it is addressed, and may contain information
that is
privileged, confidential and exempt from disclosure under
applicable
law. Unless you are the addressee (or authorized to receive
for the
addressee), you may not use, copy or disclose the message or any 
information contained in the message. If you have received this
message in error, please advise the sender by reply e-mail , and 
delete the message, or call (collect) 001 613 747 4698. *
________________________________________________________________ __ 
__
__
____________
* This message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that 
is privileged, confidential and exempt from disclosure under
applicable law. Unless you are the addressee (or authorized to
receive for the addressee), you may not use, copy or disclose the 
message or any information contained in the message. If you have
received this message in error, please advise the sender by
reply e-
mail , and delete the message, or call (collect) 001 613 747
4698. *
__________________________________________________________________ __ 
__
____________
* This message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that
is privileged, confidential and exempt from disclosure under
applicable law. Unless you are the addressee (or authorized to
receive for the addressee), you may not use, copy or disclose the
message or any information contained in the message. If you have
received this message in error, please advise the sender by reply e- mail , and delete the message, or call (collect) 001 613 747 4698. *
____________________________________________________________________ __ 
____________
* This message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that
is privileged, confidential and exempt from disclosure under
applicable law. Unless you are the addressee (or authorized to
receive for the addressee), you may not use, copy or disclose the
message or any information contained in the message. If you have
received this message in error, please advise the sender by reply e-
mail , and delete the message, or call (collect) 001 613 747 4698. *
______________________________________________________________________ ____________ * This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose the message or any information contained in the message. If you have received this message in error, please advise the sender by reply e- mail , and delete the message, or call (collect) 001 613 747 4698. *

Reply via email to