You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Francois Papon <fr...@openobject.fr> on 2019/07/23 21:00:11 UTC
[OSGi] - Configuration and classloader
Hi guys,
After many brainstorming with JB and make some tests on the integration
of Shiro in OSGi and especially with Karaf, I noticed that we have some
classloader issues that we have to deal with.
A good example is the SecurityUtils class that is a singleton and if we
want to configure multiple SecurityManager, we can't do that as is.
We have one singleton per classloader and if we install the shiro-core
feature, the configuration is the same for all the services.
So it would be great if we can choose how to configure the security manager:
- on each services (with one configuration file per service and
declaring shiro bundles as private package)
- global to the runtime (with only one configuration file and installing
shiro features)
Another things is the instanciation of the class that is defined in the
shiro.ini and the usage of the ReflectionBuilder with Apache Commons
BeanUtils.
We have some classNotFound issues that is related to the classloader
design of OSGi. We can also deal with some private package to fix that.
We have some tutorials and we could add them to the Shiro website :)
Thoughts?
regards,
--
François
fpapon@apache.org
Re: [OSGi] - Configuration and classloader
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
I started something similar with a Shiro service.
I will share the PR later today.
Regards
JB
Le 24 juil. 2019 à 12:32, à 12:32, Steinar Bang <sb...@dod.no> a écrit:
>>>>>> Francois Papon
><fr...@public.gmane.org>:
>
>> Thoughts?
>
>I'm excited to see this, because of authservice
>https://github.com/steinarb/authservice#forms-based-nginx-login-and-pluggable-shiro-auth-in-karaf
>
>I'm currently doing configuration as a combination of
> 1. OSGi service dependency injection (that's how I get the Realm and
> the SessionDAO) into the web whiteboard shiro filter DS component
>https://github.com/steinarb/authservice/blob/master/authservice.web.security/src/main/java/no/priv/bang/authservice/web/security/AuthserviceShiroFilter.java#L63
> 2. Code in the DS component of the whiteboard shiro filter (and the
> WebIniSecurityManagerFactory() I'm using her is deperecated so I've
> be happy to replace it once I figure out what it can be replaced
> with...)
>https://github.com/steinarb/authservice/blob/master/authservice.web.security/src/main/java/no/priv/bang/authservice/web/security/AuthserviceShiroFilter.java#L74
>3. A shiro.ini file handling URL to user/role/permission mapping (can't
> use this for the rest of the config because I get class not found
> exception)
Re: [OSGi] - Configuration and classloader
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Steinar Bang <sb...@public.gmane.org>:
>>>>> Francois Papon <fr...@public.gmane.org>:
>> Hi Steinar,
>> I started some test projects, you can take a look here:
>> https://github.com/fpapon/shiro-labs
> thanks! I may be able to replace the deprecated
> WebIniSecurityManagerFactory with stuff from here:
> https://github.com/fpapon/shiro-labs/blob/master/karaf-jaxrs/src/main/java/fr/openobject/labs/shiro/karaf/jaxrs/ShiroService.java#L48
Well, it got me part of the way.
I was able to replace the WebIniSecurityManagerFactory deprecated class,
but I was unable to replace the use of the IniFilterChainResolverFactory:
https://github.com/steinarb/authservice/blob/master/authservice.web.security/src/main/java/no/priv/bang/authservice/web/security/AuthserviceShiroFilter.java#L90
Much of the logic for setting up a filter chain seems to be in the
IniFilterChainResolverFactory and doing it manually looked like I would
need to copy a lot of the code of IniFilterChainResolverFactory.
Re: [OSGi] - Configuration and classloader
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Francois Papon <fr...@public.gmane.org>:
> Hi Steinar,
> I started some test projects, you can take a look here:
> https://github.com/fpapon/shiro-labs
thanks! I may be able to replace the deprecated
WebIniSecurityManagerFactory with stuff from here:
https://github.com/fpapon/shiro-labs/blob/master/karaf-jaxrs/src/main/java/fr/openobject/labs/shiro/karaf/jaxrs/ShiroService.java#L48
Note that there are two Shiro interfaces (there may be more, but those
two at least), where it may be best to have one bundle per
implementation of the service.
The two interfaces are Realm and SessionDAO.
I have one DS component implementing JdbcRealm and exposing a Realm
service, and one component implementing MemorySessio and exposing a
SessionDAO service.
https://github.com/steinarb/authservice/blob/master/authservice.web.security.dbrealm/src/main/java/no/priv/bang/authservice/web/security/dbrealm/AuthserviceDbRealm.java#L25
https://github.com/steinarb/authservice/blob/master/authservice.web.security.memorysession/src/main/java/no/priv/bang/authservice/web/security/memorysession/MemorySession.java#L23
The idea is that one could pick the realm (JDBC, LDAP, shiro.ini
password), and session manager, simply by requiring karaf features.
I'm already using a shiro.ini-backed realm in the unit tests, since that
is much cheaper to start and initialize than the JdbcRealm.
For session managemen used by my "cross-webapp-poor-man's-single-signon"
I'm using a simple MemorySession, but one could potentially have a
persistent session management based on EHCache.
Re: [OSGi] - Configuration and classloader
Posted by Francois Papon <fr...@openobject.fr>.
Hi Steinar,
I started some test projects, you can take a look here:
https://github.com/fpapon/shiro-labs
regards,
François
fpapon@apache.org
Le 24/07/2019 à 12:32, Steinar Bang a écrit :
>>>>>> Francois Papon <fr...@public.gmane.org>:
>> Thoughts?
> I'm excited to see this, because of authservice
> https://github.com/steinarb/authservice#forms-based-nginx-login-and-pluggable-shiro-auth-in-karaf
>
> I'm currently doing configuration as a combination of
> 1. OSGi service dependency injection (that's how I get the Realm and
> the SessionDAO) into the web whiteboard shiro filter DS component
> https://github.com/steinarb/authservice/blob/master/authservice.web.security/src/main/java/no/priv/bang/authservice/web/security/AuthserviceShiroFilter.java#L63
> 2. Code in the DS component of the whiteboard shiro filter (and the
> WebIniSecurityManagerFactory() I'm using her is deperecated so I've
> be happy to replace it once I figure out what it can be replaced
> with...)
> https://github.com/steinarb/authservice/blob/master/authservice.web.security/src/main/java/no/priv/bang/authservice/web/security/AuthserviceShiroFilter.java#L74
> 3. A shiro.ini file handling URL to user/role/permission mapping (can't
> use this for the rest of the config because I get class not found
> exception)
Re: [OSGi] - Configuration and classloader
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Francois Papon <fr...@public.gmane.org>:
> Thoughts?
I'm excited to see this, because of authservice
https://github.com/steinarb/authservice#forms-based-nginx-login-and-pluggable-shiro-auth-in-karaf
I'm currently doing configuration as a combination of
1. OSGi service dependency injection (that's how I get the Realm and
the SessionDAO) into the web whiteboard shiro filter DS component
https://github.com/steinarb/authservice/blob/master/authservice.web.security/src/main/java/no/priv/bang/authservice/web/security/AuthserviceShiroFilter.java#L63
2. Code in the DS component of the whiteboard shiro filter (and the
WebIniSecurityManagerFactory() I'm using her is deperecated so I've
be happy to replace it once I figure out what it can be replaced
with...)
https://github.com/steinarb/authservice/blob/master/authservice.web.security/src/main/java/no/priv/bang/authservice/web/security/AuthserviceShiroFilter.java#L74
3. A shiro.ini file handling URL to user/role/permission mapping (can't
use this for the rest of the config because I get class not found
exception)
Re: [OSGi] - Configuration and classloader
Posted by jb...@nanthrax.net,
jb...@nanthrax.net.
I'm working on PR today to illustrate the "private" approach.
I will share on this thread for discussion.
Regards
JB
On Wednesday, July 24, 2019 06:43 CEST, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
Yeah, agree. That's why I think it makes more sense to embed shiro as private. We just have to document and provide an example.
Regards
JB
Le 23 juil. 2019 à 23:49, à 23:49, Brian Demers <br...@gmail.com> a écrit:
>IMHO in web environment, you typically do NOT want to set the static
>instance of the SecurityManager. But instead, bind it to the request
>(or
>similar context).
>
>In our Spring integration (and I assume Guice) we expose the
>SecurityManger
>as a bean, can you do something similar?
>
>I'm not sure if this helps much, as you still might have a problem
>between
>classloaders (depending on the structure).
>
>On Tue, Jul 23, 2019 at 5:13 PM jb@nanthrax.net <jb...@nanthrax.net>
>wrote:
>
>>>> Hi,
>>
>> Actually, I think it's not a good idea to provide a Shiro Karaf
>feature as
>> it is, without details. As we are using singleton and configuration
>loaded
>> by TCCL, it means that all will be in an unique classloader and
>doesn't
>> work as expected.
>>
>> I think it makes more sense to embed Shiro as private package in
>"client"
>> bundles. It will work directly without any pain.
>>
>> I would like to submit a PR with the following:
>>
>> - add a Karaf/OSGi Shiro global approach (via Karaf feature) with a
>Shiro
>> "service". It means we will have an unique security manager and
>unique
>> configuration.
>> - add a Karaf/OSGi example to use "multiple" Shiro manager, as
>private
>> package on the "client" bundles.
>>
>> I would like to add this in examples folder with some details and use
>> cases.
>>
>> If you agree, I will create the PR tomorrow.
>>
>> I have also other OSGi improvements on the way.
>>
>> Regards
>> JB
>>
>> On Tuesday, July 23, 2019 23:00 CEST, Francois Papon <
>> francois.papon@openobject.fr> wrote:
>> Hi guys,
>>
>> After many brainstorming with JB and make some tests on the
>integration
>> of Shiro in OSGi and especially with Karaf, I noticed that we have
>some
>> classloader issues that we have to deal with.
>>
>> A good example is the SecurityUtils class that is a singleton and if
>we
>> want to configure multiple SecurityManager, we can't do that as is.
>>
>> We have one singleton per classloader and if we install the
>shiro-core
>> feature, the configuration is the same for all the services.
>>
>> So it would be great if we can choose how to configure the security
>> manager:
>>
>> - on each services (with one configuration file per service and
>> declaring shiro bundles as private package)
>>
>> - global to the runtime (with only one configuration file and
>installing
>> shiro features)
>>
>> Another things is the instanciation of the class that is defined in
>the
>> shiro.ini and the usage of the ReflectionBuilder with Apache Commons
>> BeanUtils.
>>
>> We have some classNotFound issues that is related to the classloader
>> design of OSGi. We can also deal with some private package to fix
>that.
>>
>> We have some tutorials and we could add them to the Shiro website :)
>>
>> Thoughts?
>>
>> regards,
>>>> --
>> François
>> fpapon@apache.org
>>
>>
>>
>>
>>
>>
Re: [OSGi] - Configuration and classloader
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yeah, agree. That's why I think it makes more sense to embed shiro as private. We just have to document and provide an example.
Regards
JB
Le 23 juil. 2019 à 23:49, à 23:49, Brian Demers <br...@gmail.com> a écrit:
>IMHO in web environment, you typically do NOT want to set the static
>instance of the SecurityManager. But instead, bind it to the request
>(or
>similar context).
>
>In our Spring integration (and I assume Guice) we expose the
>SecurityManger
>as a bean, can you do something similar?
>
>I'm not sure if this helps much, as you still might have a problem
>between
>classloaders (depending on the structure).
>
>On Tue, Jul 23, 2019 at 5:13 PM jb@nanthrax.net <jb...@nanthrax.net>
>wrote:
>
>>
>> Hi,
>>
>> Actually, I think it's not a good idea to provide a Shiro Karaf
>feature as
>> it is, without details. As we are using singleton and configuration
>loaded
>> by TCCL, it means that all will be in an unique classloader and
>doesn't
>> work as expected.
>>
>> I think it makes more sense to embed Shiro as private package in
>"client"
>> bundles. It will work directly without any pain.
>>
>> I would like to submit a PR with the following:
>>
>> - add a Karaf/OSGi Shiro global approach (via Karaf feature) with a
>Shiro
>> "service". It means we will have an unique security manager and
>unique
>> configuration.
>> - add a Karaf/OSGi example to use "multiple" Shiro manager, as
>private
>> package on the "client" bundles.
>>
>> I would like to add this in examples folder with some details and use
>> cases.
>>
>> If you agree, I will create the PR tomorrow.
>>
>> I have also other OSGi improvements on the way.
>>
>> Regards
>> JB
>>
>> On Tuesday, July 23, 2019 23:00 CEST, Francois Papon <
>> francois.papon@openobject.fr> wrote:
>> Hi guys,
>>
>> After many brainstorming with JB and make some tests on the
>integration
>> of Shiro in OSGi and especially with Karaf, I noticed that we have
>some
>> classloader issues that we have to deal with.
>>
>> A good example is the SecurityUtils class that is a singleton and if
>we
>> want to configure multiple SecurityManager, we can't do that as is.
>>
>> We have one singleton per classloader and if we install the
>shiro-core
>> feature, the configuration is the same for all the services.
>>
>> So it would be great if we can choose how to configure the security
>> manager:
>>
>> - on each services (with one configuration file per service and
>> declaring shiro bundles as private package)
>>
>> - global to the runtime (with only one configuration file and
>installing
>> shiro features)
>>
>> Another things is the instanciation of the class that is defined in
>the
>> shiro.ini and the usage of the ReflectionBuilder with Apache Commons
>> BeanUtils.
>>
>> We have some classNotFound issues that is related to the classloader
>> design of OSGi. We can also deal with some private package to fix
>that.
>>
>> We have some tutorials and we could add them to the Shiro website :)
>>
>> Thoughts?
>>
>> regards,
>>
>> --
>> François
>> fpapon@apache.org
>>
>>
>>
>>
>>
>>
Re: [OSGi] - Configuration and classloader
Posted by Brian Demers <br...@gmail.com>.
IMHO in web environment, you typically do NOT want to set the static
instance of the SecurityManager. But instead, bind it to the request (or
similar context).
In our Spring integration (and I assume Guice) we expose the SecurityManger
as a bean, can you do something similar?
I'm not sure if this helps much, as you still might have a problem between
classloaders (depending on the structure).
On Tue, Jul 23, 2019 at 5:13 PM jb@nanthrax.net <jb...@nanthrax.net> wrote:
>
> Hi,
>
> Actually, I think it's not a good idea to provide a Shiro Karaf feature as
> it is, without details. As we are using singleton and configuration loaded
> by TCCL, it means that all will be in an unique classloader and doesn't
> work as expected.
>
> I think it makes more sense to embed Shiro as private package in "client"
> bundles. It will work directly without any pain.
>
> I would like to submit a PR with the following:
>
> - add a Karaf/OSGi Shiro global approach (via Karaf feature) with a Shiro
> "service". It means we will have an unique security manager and unique
> configuration.
> - add a Karaf/OSGi example to use "multiple" Shiro manager, as private
> package on the "client" bundles.
>
> I would like to add this in examples folder with some details and use
> cases.
>
> If you agree, I will create the PR tomorrow.
>
> I have also other OSGi improvements on the way.
>
> Regards
> JB
>
> On Tuesday, July 23, 2019 23:00 CEST, Francois Papon <
> francois.papon@openobject.fr> wrote:
> Hi guys,
>
> After many brainstorming with JB and make some tests on the integration
> of Shiro in OSGi and especially with Karaf, I noticed that we have some
> classloader issues that we have to deal with.
>
> A good example is the SecurityUtils class that is a singleton and if we
> want to configure multiple SecurityManager, we can't do that as is.
>
> We have one singleton per classloader and if we install the shiro-core
> feature, the configuration is the same for all the services.
>
> So it would be great if we can choose how to configure the security
> manager:
>
> - on each services (with one configuration file per service and
> declaring shiro bundles as private package)
>
> - global to the runtime (with only one configuration file and installing
> shiro features)
>
> Another things is the instanciation of the class that is defined in the
> shiro.ini and the usage of the ReflectionBuilder with Apache Commons
> BeanUtils.
>
> We have some classNotFound issues that is related to the classloader
> design of OSGi. We can also deal with some private package to fix that.
>
> We have some tutorials and we could add them to the Shiro website :)
>
> Thoughts?
>
> regards,
>
> --
> François
> fpapon@apache.org
>
>
>
>
>
>
Re: [OSGi] - Configuration and classloader
Posted by jb...@nanthrax.net,
jb...@nanthrax.net.
Hi,
Actually, I think it's not a good idea to provide a Shiro Karaf feature as it is, without details. As we are using singleton and configuration loaded by TCCL, it means that all will be in an unique classloader and doesn't work as expected.
I think it makes more sense to embed Shiro as private package in "client" bundles. It will work directly without any pain.
I would like to submit a PR with the following:
- add a Karaf/OSGi Shiro global approach (via Karaf feature) with a Shiro "service". It means we will have an unique security manager and unique configuration.
- add a Karaf/OSGi example to use "multiple" Shiro manager, as private package on the "client" bundles.
I would like to add this in examples folder with some details and use cases.
If you agree, I will create the PR tomorrow.
I have also other OSGi improvements on the way.
Regards
JB
On Tuesday, July 23, 2019 23:00 CEST, Francois Papon <fr...@openobject.fr> wrote:
Hi guys,
After many brainstorming with JB and make some tests on the integration
of Shiro in OSGi and especially with Karaf, I noticed that we have some
classloader issues that we have to deal with.
A good example is the SecurityUtils class that is a singleton and if we
want to configure multiple SecurityManager, we can't do that as is.
We have one singleton per classloader and if we install the shiro-core
feature, the configuration is the same for all the services.
So it would be great if we can choose how to configure the security manager:
- on each services (with one configuration file per service and
declaring shiro bundles as private package)
- global to the runtime (with only one configuration file and installing
shiro features)
Another things is the instanciation of the class that is defined in the
shiro.ini and the usage of the ReflectionBuilder with Apache Commons
BeanUtils.
We have some classNotFound issues that is related to the classloader
design of OSGi. We can also deal with some private package to fix that.
We have some tutorials and we could add them to the Shiro website :)
Thoughts?
regards,
--
François
fpapon@apache.org