geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo role security
Date Wed, 18 Jul 2007 21:00:23 GMT
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 <david_jencks@yahoo.com> 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.SimpleCredentialStoreIm 
>>> pl
>>> .getSubject(SimpleCredentialStoreImpl.java:82)
>>>       at
>>> org.apache.geronimo.security.credentialstore.SimpleCredentialStoreIm 
>>> 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.ApplicationPolicyConfigurationMana 
>>> 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.attemptFullStar 
>>> 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.fireRunningEv 
>>> 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.attemptFullStar 
>>> t(
>>> GBeanInstanceState.java:294)
>>>       at
>>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start
>>> (GBeanInstanceState.java:102)
>>>       at
>>> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive
>>> (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.startConfigurati 
>>> on
>>> GBeans(ConfigurationUtil.java:448)
>>>       at
>>> org.apache.geronimo.kernel.config.KernelConfigurationManager.start
>>> (KernelConfigurationManager.java:187)
>>>       at
>>> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startCo 
>>> 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.GeronimoGroupPri 
>>> 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.SimpleCredential 
>>> 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.NameCallbackHandl 
>>> er
>>> </type>
>>>                       <value>ananner</value>
>>>                    </credential>
>>>                    <credential>
>>>
>>> <type>org.apache.geronimo.security.credentialstore.PasswordCallbackH 
>>> an
>>> dler</type>
>>>                       <value>password</value>
>>>                    </credential>
>>>                </subject>
>>>             </realm>
>>>          </credential-store>
>>>       </xml-attribute>
>>>    </sys:gbean>
>>> ----------
>>>
>>>
>>>
>>> David Jencks <david_jencks@yahoo.com> 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.SimpleCredentia 
>>>> 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.NameCallbackHand

>>>> le
>>>> r</
>>>> type>
>>>>                              <value>system</value>
>>>>                          </credential>
>>>>                          <credential>
>>>>
>>>> <type>org.apache.geronimo.security.credentialstore.PasswordCallback

>>>> 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.GeronimoGroupPr 
>>>> 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 <aman.nanner@mxi.com> 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.GeronimoUserPr 
>>>>> in
>>>>> ci
>>>>> pal"
>>>>>> name="" />
>>>>>>       </security:default-principal>
>>>>>>       <security:role-mappings>
>>>>>>          <security:role role-name="TESTSYSTEM">
>>>>>>             <security:principal
>>>>>>
>>>>> class="org.apache.geronimo.security.realm.providers.GeronimoUserPr 
>>>>> 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. *
>


Mime
View raw message