You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Peter Ledbrook <pe...@g2one.com> on 2008/10/07 14:51:40 UTC
Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
Hi,
I'm forwarding this to the JSecurity mailing list since it relates the
the core JSecurity classes.
Cheers,
Peter
2008/10/6 Skowronek <ts...@wi.rr.com>:
>
> I have a Grails application using version 1.0.3. The JSecurity plugin
> version 0.3-SNAPSHOT is installed.
>
> I created a realm called AdamRealm, which extends AbstractLdapRealm to take
> advantage of the services in the hierarchy. Specifically caching.
> AdamRealm is very similar to ActiveDirectoryRealm.
>
> After launching the app, the realm is created as well as the CacheManager as
> shown in the log entries below.
>
> [com.jud.realm.AdamRealm] AdamRealm created
> [org.jsecurity.mgt.CachingSecurityManager] Attempting to initialize default
> CacheManager using EhCache...
> [org.jsecurity.cache.ehcache.EhCacheManager] cacheManager property not set.
> Constructing CacheManager instance...
> [org.jsecurity.io.ResourceUtils] Opening resource from class path
> [org/jsecurity/cache/ehcache/ehcache.xml]...
> [org.jsecurity.cache.ehcache.EhCacheManager] instantiated Ehcache
> CacheManager instance.
> [org.jsecurity.cache.ehcache.EhCacheManager] implicit cacheManager created
> successfully.
>
>
> If a user tries to access a restricted resource for the first time, I see
> that the queryForAuthenticationInfo(AuthenticationToken token,
> LdapContextFactory ldapContextFactory) implementation is called as expected
> and the user is authenticated.
>
> [com.jud.realm.AdamRealm] queryForAuthenticationInfo started
> DEBUG [org.jsecurity.authc.AbstractAuthenticator] Authentication successful
> for token [org.jsecurity.authc.UsernamePasswordToken - abc00,
> rememberMe=false]. Returned account:
> [org.jsecurity.subject.SimplePrincipalCollection@3fe59b3e]
>
>
> Next, the the queryForAuthorizationInfo(PrincipalCollection principals,
> LdapContextFactory ldapContextFactory) implementation is called as expected
> since this is the first time a restricted resource is being accessed by the
> user.
>
> DEBUG [com.jud.realm.AdamRealm] queryForAuthorizationInfo started
>
> My understanding is that for all subsequent requests made by the user, the
> queryForAuthorizationInfo() shouldn't be called. Instead,
> AuthorizingRealm.getAuthorizationInfo(PrincipalCollection principals) should
> pull the AuthorizationInfo from the cache, but that doesn't happen. For
> every subsequent request, I see the queryForAuthorizationInfo() being
> called.
>
> Any assistance on how to get the realm to pull the AuthorizationInfo from
> the cache would be appreciated.
>
> Thank you.
>
> --
> View this message in context: http://www.nabble.com/JSecurity-Plugin%2C-AbstractLdapRealm-and-Caching-tp19843999p19843999.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
--
Software Engineer
G2One, Inc.
http://www.g2one.com/
RE: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
Posted by Thomas Skowronek <ts...@wi.rr.com>.
Les and Peter,
Making the following change fixed the problem. Subsequent requests are now
accessing the cache.
"mgr.realms += beans.collect { applicationContext.getBean(it) }"
Thanks for all your help on this issue. I really appreciate it.
Best regards,
Thomas
-----Original Message-----
From: Peter Ledbrook [mailto:peter@g2one.com]
Sent: Friday, October 17, 2008 12:38 AM
To: user@grails.codehaus.org
Cc: jsecurity-dev@incubator.apache.org
Subject: Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
> DefaultWebSecurityManager securityManager = new
DefaultWebSecurityManager();
> securityManager.init(); // <-- the securityManager has a default
> EhCacheCacheManager if ehcache is in the classpath, but your Realm
> doesn't have it yet
>
> securityManager.setRealm( myRealm );
> //now 'myRealm' will have the cacheManager instance and its
> AuthorizationInfo cache will be created.
Ah, I think I can see what the problem is. The normal realms
configured by the plugin are added in the bean definition, so they
will be initialised during "securityManager.init()". However, I add
native JSecurity realms once the security manager has been
instantiated:
100 // Finally add the remaining beans to the security manager.
101 log.info "Registering native realms: $beans"
102 def mgr = applicationContext.getBean('jsecSecurityManager')
103 mgr.realms.addAll(beans.collect {
applicationContext.getBean(it) })
Since I'm adding the beans to the existing realms collection, the
cache manager stuff is not triggered for those realms. This is already
a hack, since plugins can't see bean definitions from
"resources.groovy" or "resources.xml". I could just call "mgr.realms
+= beans.collect { applicationContext.getBean(it) }".
Cheers,
Peter
--
Software Engineer
G2One, Inc.
http://www.g2one.com/
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
Posted by Peter Ledbrook <pe...@g2one.com>.
> DefaultWebSecurityManager securityManager = new DefaultWebSecurityManager();
> securityManager.init(); // <-- the securityManager has a default
> EhCacheCacheManager if ehcache is in the classpath, but your Realm
> doesn't have it yet
>
> securityManager.setRealm( myRealm );
> //now 'myRealm' will have the cacheManager instance and its
> AuthorizationInfo cache will be created.
Ah, I think I can see what the problem is. The normal realms
configured by the plugin are added in the bean definition, so they
will be initialised during "securityManager.init()". However, I add
native JSecurity realms once the security manager has been
instantiated:
100 // Finally add the remaining beans to the security manager.
101 log.info "Registering native realms: $beans"
102 def mgr = applicationContext.getBean('jsecSecurityManager')
103 mgr.realms.addAll(beans.collect { applicationContext.getBean(it) })
Since I'm adding the beans to the existing realms collection, the
cache manager stuff is not triggered for those realms. This is already
a hack, since plugins can't see bean definitions from
"resources.groovy" or "resources.xml". I could just call "mgr.realms
+= beans.collect { applicationContext.getBean(it) }".
Cheers,
Peter
--
Software Engineer
G2One, Inc.
http://www.g2one.com/
Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
Posted by Les Hazlewood <lh...@apache.org>.
Hi Thomas,
I was looking at this email again in conjunction with another thread
related to caching.
The output looks correct, but there is a disconnect happening
somewhere, and I'm not sure if it is related to the Grails plugin or
not:
Summarizing the other thread found here
(http://jsecurity.markmail.org/search/?q=#query:+page:1+mid:6tqxg6ttxsouj6o2+state:results),
if you call securityMangaer.setCacheManager() _or_
securityManager.setRealm(s), in either case, the CacheManager will be
made available to any CachingRealm subclass instances that you inject
into the security manager. Once they receive it, if it is also an
AuthorizingRealm child, it will then immediately build their
AuthorizationInfo cache (AbstractLdapRealm is such a child subclass).
So, as you can see, in either case, your AuthorizationInfo cache
_should_ be created in any event. It might not be created when it is
first initialized, but it will be created eventually.
For example:
Realm myRealm = new MyLdapRealm();
myRealm.init(); // <-- no AuthorizationInfo cache yet
DefaultWebSecurityManager securityManager = new DefaultWebSecurityManager();
securityManager.init(); // <-- the securityManager has a default
EhCacheCacheManager if ehcache is in the classpath, but your Realm
doesn't have it yet
securityManager.setRealm( myRealm );
//now 'myRealm' will have the cacheManager instance and its
AuthorizationInfo cache will be created.
Does this help?
Peter, I'm assuming the Grails plugin does something similar. Am I correct?
On Mon, Oct 13, 2008 at 4:25 PM, Thomas Skowronek <ts...@wi.rr.com> wrote:
> To provide additional information, I have a no-arg constructor in my realm.
> After calling super(), I just added a call to init() in it to see if I could
> get the additional output you mentioned. The log output follows. It looks
> like the default cache manager is created after the realm.
>
> Should the security manager initialize the realm or should the realm
> initialize itself?
>
>
> [com.jud.realm.AdamRealm] AdamRealm created
> [org.jsecurity.realm.AuthorizingRealm] Initializing authorization cache.
> [org.jsecurity.realm.AuthorizingRealm] No cache implementation set.
> Checking cacheManager...
> [org.jsecurity.realm.AuthorizingRealm] No cache or cacheManager properties
> have been set. Authorization caching is disabled.
> [com.jud.realm.AdamRealm] AdamRealm initialized
> [com.jud.realm.AdamRealm] Realm Name: com.palmharbor.jud.realm.AdamRealm_0
> [org.jsecurity.mgt.CachingSecurityManager] Attempting to initialize default
> CacheManager using EhCache...
> [org.jsecurity.cache.ehcache.EhCacheManager] cacheManager property not set.
> Constructing CacheManager instance...
> [org.jsecurity.io.ResourceUtils] Opening resource from class path
> [org/jsecurity/cache/ehcache/ehcache.xml]...
> [org.jsecurity.cache.ehcache.EhCacheManager] instantiated Ehcache
> CacheManager instance.
> [org.jsecurity.cache.ehcache.EhCacheManager] implicit cacheManager created
> successfully.
> [org.jsecurity.web.DefaultWebSecurityManager] http mode - enabling
> ServletContainerSessionManager (Http Sessions)
>
> -----Original Message-----
> From: Thomas Skowronek [mailto:tskowronek@wi.rr.com]
> Sent: Monday, October 13, 2008 2:17 PM
> To: jsecurity-dev@incubator.apache.org
> Cc: user@grails.codehaus.org
> Subject: RE: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
>
> My apologies for the slow response. Vacation.
>
> With trace enabled, the only output that I get from AuthorizingRealm is the
> following in getAuthorizationInfo().
>
> 2008-10-13 13:33:26,896 TRACE [org.jsecurity.realm.AuthorizingRealm]
> Retrieving AuthorizationInfo for principals
> [org.jsecurity.subject.SimplePrincipalCollection@396e7520]
>
> There is no output from initAuthorizationCache().
>
>
> Thomas
>
> -----Original Message-----
> From: Les Hazlewood [mailto:lhazlewood@apache.org]
> Sent: Tuesday, October 07, 2008 6:08 PM
> To: jsecurity-dev@incubator.apache.org
> Cc: user@grails.codehaus.org
> Subject: Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
>
> You are indeed correct that it should be caching the AuthorizationInfo
> lookup for role/permission checks - at least that is what the code
> 'says'.
>
> There are a few trace/debug/info log messages in AuthorizingRealm that
> are printed when an authorization check occurs, particularly in the
> initAuthorizationCache() and getAuthorizationInfo() methods . Do you
> have that output?
>
> - Les
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
RE: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
Posted by Thomas Skowronek <ts...@wi.rr.com>.
To provide additional information, I have a no-arg constructor in my realm.
After calling super(), I just added a call to init() in it to see if I could
get the additional output you mentioned. The log output follows. It looks
like the default cache manager is created after the realm.
Should the security manager initialize the realm or should the realm
initialize itself?
[com.jud.realm.AdamRealm] AdamRealm created
[org.jsecurity.realm.AuthorizingRealm] Initializing authorization cache.
[org.jsecurity.realm.AuthorizingRealm] No cache implementation set.
Checking cacheManager...
[org.jsecurity.realm.AuthorizingRealm] No cache or cacheManager properties
have been set. Authorization caching is disabled.
[com.jud.realm.AdamRealm] AdamRealm initialized
[com.jud.realm.AdamRealm] Realm Name: com.palmharbor.jud.realm.AdamRealm_0
[org.jsecurity.mgt.CachingSecurityManager] Attempting to initialize default
CacheManager using EhCache...
[org.jsecurity.cache.ehcache.EhCacheManager] cacheManager property not set.
Constructing CacheManager instance...
[org.jsecurity.io.ResourceUtils] Opening resource from class path
[org/jsecurity/cache/ehcache/ehcache.xml]...
[org.jsecurity.cache.ehcache.EhCacheManager] instantiated Ehcache
CacheManager instance.
[org.jsecurity.cache.ehcache.EhCacheManager] implicit cacheManager created
successfully.
[org.jsecurity.web.DefaultWebSecurityManager] http mode - enabling
ServletContainerSessionManager (Http Sessions)
-----Original Message-----
From: Thomas Skowronek [mailto:tskowronek@wi.rr.com]
Sent: Monday, October 13, 2008 2:17 PM
To: jsecurity-dev@incubator.apache.org
Cc: user@grails.codehaus.org
Subject: RE: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
My apologies for the slow response. Vacation.
With trace enabled, the only output that I get from AuthorizingRealm is the
following in getAuthorizationInfo().
2008-10-13 13:33:26,896 TRACE [org.jsecurity.realm.AuthorizingRealm]
Retrieving AuthorizationInfo for principals
[org.jsecurity.subject.SimplePrincipalCollection@396e7520]
There is no output from initAuthorizationCache().
Thomas
-----Original Message-----
From: Les Hazlewood [mailto:lhazlewood@apache.org]
Sent: Tuesday, October 07, 2008 6:08 PM
To: jsecurity-dev@incubator.apache.org
Cc: user@grails.codehaus.org
Subject: Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
You are indeed correct that it should be caching the AuthorizationInfo
lookup for role/permission checks - at least that is what the code
'says'.
There are a few trace/debug/info log messages in AuthorizingRealm that
are printed when an authorization check occurs, particularly in the
initAuthorizationCache() and getAuthorizationInfo() methods . Do you
have that output?
- Les
RE: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
Posted by Thomas Skowronek <ts...@wi.rr.com>.
My apologies for the slow response. Vacation.
With trace enabled, the only output that I get from AuthorizingRealm is the
following in getAuthorizationInfo().
2008-10-13 13:33:26,896 TRACE [org.jsecurity.realm.AuthorizingRealm]
Retrieving AuthorizationInfo for principals
[org.jsecurity.subject.SimplePrincipalCollection@396e7520]
There is no output from initAuthorizationCache().
Thomas
-----Original Message-----
From: Les Hazlewood [mailto:lhazlewood@apache.org]
Sent: Tuesday, October 07, 2008 6:08 PM
To: jsecurity-dev@incubator.apache.org
Cc: user@grails.codehaus.org
Subject: Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
You are indeed correct that it should be caching the AuthorizationInfo
lookup for role/permission checks - at least that is what the code
'says'.
There are a few trace/debug/info log messages in AuthorizingRealm that
are printed when an authorization check occurs, particularly in the
initAuthorizationCache() and getAuthorizationInfo() methods . Do you
have that output?
- Les
On Tue, Oct 7, 2008 at 8:51 AM, Peter Ledbrook <pe...@g2one.com> wrote:
> Hi,
>
> I'm forwarding this to the JSecurity mailing list since it relates the
> the core JSecurity classes.
>
> Cheers,
>
> Peter
>
> 2008/10/6 Skowronek <ts...@wi.rr.com>:
>>
>> I have a Grails application using version 1.0.3. The JSecurity plugin
>> version 0.3-SNAPSHOT is installed.
>>
>> I created a realm called AdamRealm, which extends AbstractLdapRealm to
take
>> advantage of the services in the hierarchy. Specifically caching.
>> AdamRealm is very similar to ActiveDirectoryRealm.
>>
>> After launching the app, the realm is created as well as the CacheManager
as
>> shown in the log entries below.
>>
>> [com.jud.realm.AdamRealm] AdamRealm created
>> [org.jsecurity.mgt.CachingSecurityManager] Attempting to initialize
default
>> CacheManager using EhCache...
>> [org.jsecurity.cache.ehcache.EhCacheManager] cacheManager property not
set.
>> Constructing CacheManager instance...
>> [org.jsecurity.io.ResourceUtils] Opening resource from class path
>> [org/jsecurity/cache/ehcache/ehcache.xml]...
>> [org.jsecurity.cache.ehcache.EhCacheManager] instantiated Ehcache
>> CacheManager instance.
>> [org.jsecurity.cache.ehcache.EhCacheManager] implicit cacheManager
created
>> successfully.
>>
>>
>> If a user tries to access a restricted resource for the first time, I see
>> that the queryForAuthenticationInfo(AuthenticationToken token,
>> LdapContextFactory ldapContextFactory) implementation is called as
expected
>> and the user is authenticated.
>>
>> [com.jud.realm.AdamRealm] queryForAuthenticationInfo started
>> DEBUG [org.jsecurity.authc.AbstractAuthenticator] Authentication
successful
>> for token [org.jsecurity.authc.UsernamePasswordToken - abc00,
>> rememberMe=false]. Returned account:
>> [org.jsecurity.subject.SimplePrincipalCollection@3fe59b3e]
>>
>>
>> Next, the the queryForAuthorizationInfo(PrincipalCollection principals,
>> LdapContextFactory ldapContextFactory) implementation is called as
expected
>> since this is the first time a restricted resource is being accessed by
the
>> user.
>>
>> DEBUG [com.jud.realm.AdamRealm] queryForAuthorizationInfo started
>>
>> My understanding is that for all subsequent requests made by the user,
the
>> queryForAuthorizationInfo() shouldn't be called. Instead,
>> AuthorizingRealm.getAuthorizationInfo(PrincipalCollection principals)
should
>> pull the AuthorizationInfo from the cache, but that doesn't happen. For
>> every subsequent request, I see the queryForAuthorizationInfo() being
>> called.
>>
>> Any assistance on how to get the realm to pull the AuthorizationInfo from
>> the cache would be appreciated.
>>
>> Thank you.
>>
>> --
>> View this message in context:
http://www.nabble.com/JSecurity-Plugin%2C-AbstractLdapRealm-and-Caching-tp19
843999p19843999.html
>> Sent from the grails - user mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Software Engineer
> G2One, Inc.
> http://www.g2one.com/
>
Re: [grails-user] JSecurity Plugin, AbstractLdapRealm and Caching
Posted by Les Hazlewood <lh...@apache.org>.
You are indeed correct that it should be caching the AuthorizationInfo
lookup for role/permission checks - at least that is what the code
'says'.
There are a few trace/debug/info log messages in AuthorizingRealm that
are printed when an authorization check occurs, particularly in the
initAuthorizationCache() and getAuthorizationInfo() methods . Do you
have that output?
- Les
On Tue, Oct 7, 2008 at 8:51 AM, Peter Ledbrook <pe...@g2one.com> wrote:
> Hi,
>
> I'm forwarding this to the JSecurity mailing list since it relates the
> the core JSecurity classes.
>
> Cheers,
>
> Peter
>
> 2008/10/6 Skowronek <ts...@wi.rr.com>:
>>
>> I have a Grails application using version 1.0.3. The JSecurity plugin
>> version 0.3-SNAPSHOT is installed.
>>
>> I created a realm called AdamRealm, which extends AbstractLdapRealm to take
>> advantage of the services in the hierarchy. Specifically caching.
>> AdamRealm is very similar to ActiveDirectoryRealm.
>>
>> After launching the app, the realm is created as well as the CacheManager as
>> shown in the log entries below.
>>
>> [com.jud.realm.AdamRealm] AdamRealm created
>> [org.jsecurity.mgt.CachingSecurityManager] Attempting to initialize default
>> CacheManager using EhCache...
>> [org.jsecurity.cache.ehcache.EhCacheManager] cacheManager property not set.
>> Constructing CacheManager instance...
>> [org.jsecurity.io.ResourceUtils] Opening resource from class path
>> [org/jsecurity/cache/ehcache/ehcache.xml]...
>> [org.jsecurity.cache.ehcache.EhCacheManager] instantiated Ehcache
>> CacheManager instance.
>> [org.jsecurity.cache.ehcache.EhCacheManager] implicit cacheManager created
>> successfully.
>>
>>
>> If a user tries to access a restricted resource for the first time, I see
>> that the queryForAuthenticationInfo(AuthenticationToken token,
>> LdapContextFactory ldapContextFactory) implementation is called as expected
>> and the user is authenticated.
>>
>> [com.jud.realm.AdamRealm] queryForAuthenticationInfo started
>> DEBUG [org.jsecurity.authc.AbstractAuthenticator] Authentication successful
>> for token [org.jsecurity.authc.UsernamePasswordToken - abc00,
>> rememberMe=false]. Returned account:
>> [org.jsecurity.subject.SimplePrincipalCollection@3fe59b3e]
>>
>>
>> Next, the the queryForAuthorizationInfo(PrincipalCollection principals,
>> LdapContextFactory ldapContextFactory) implementation is called as expected
>> since this is the first time a restricted resource is being accessed by the
>> user.
>>
>> DEBUG [com.jud.realm.AdamRealm] queryForAuthorizationInfo started
>>
>> My understanding is that for all subsequent requests made by the user, the
>> queryForAuthorizationInfo() shouldn't be called. Instead,
>> AuthorizingRealm.getAuthorizationInfo(PrincipalCollection principals) should
>> pull the AuthorizationInfo from the cache, but that doesn't happen. For
>> every subsequent request, I see the queryForAuthorizationInfo() being
>> called.
>>
>> Any assistance on how to get the realm to pull the AuthorizationInfo from
>> the cache would be appreciated.
>>
>> Thank you.
>>
>> --
>> View this message in context: http://www.nabble.com/JSecurity-Plugin%2C-AbstractLdapRealm-and-Caching-tp19843999p19843999.html
>> Sent from the grails - user mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Software Engineer
> G2One, Inc.
> http://www.g2one.com/
>