You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Chetan Mehrotra <ch...@gmail.com> on 2012/09/26 15:56:59 UTC
Bundle to simplify JAAS usage in OSGi
I have been working on a poc to simplify usage if JAAS with Sling and
Jackrabbit. Using of JAAS within OSGi is often tricky because of
classloading issues. There has been some work done around this
1. JAAS support in Apache Karaf
2. Proposal by Stefan Vladov in the presentation [1] given by him at
OSGi Community Event 2011
Following the proposal at #2 and borrowing some ideas from Apache
Karaf I implemented a bundle which simplifies usage of JAAS within
OSGi env. It supports following features
1. It can work both in Standalone and AppServer deployments i.e. in
those environment where global JAAS configuration might be used by
other applications and our usage of JAAS should not affect them
2. It enables usage of OSGi Configuration support to dynamically
configure the login modules.
3. It allows LoginModule instances to be created via factories
registered in OSGi Service Registry
4. It does not require the client to depend on any OSGi API
5. It works well with the dynamic nature of the OSGi env
6. Implementation depends only on Core OSGi API and ConfigAdmin
Complete details are provided at [2]
Kindly have a look at it and provide feedback!!
Chetan Mehrotra
[1] http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
[2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
Re: Bundle to simplify JAAS usage in OSGi
Posted by David Jencks <da...@yahoo.com>.
I haven't looked at your proposed code yet but from your description it sounds like you have nice solutions for all the problems I'm aware of working around the JAAS apis :-)
thanks!
david jencks
On Sep 28, 2012, at 1:42 AM, Chetan Mehrotra wrote:
>> I would be interested in hearing what
>>> the differences with the Karaf implementation are.
>
> Yes I had a closer look at the JAAS support present in Karaf project.
> As mentioned earlier the proposed implementation borrows from both
> Karaf implementation and Stefan Vladov's proposal
>
> Below are couple of areas where it differs from Karaf implementation
>
> 1. Global Configuration Handling - It should be possible to use OSGi
> based JAAS support without affecting the Global configuration. For
> example if a Sling app is deployed as war on an application server
> then its usage of JAAS should not affect other applications running on
> same App Server. The Karaf implementation currently replaces the
> Global configuration. The proposed implementation uses the new
> ConfigurationSpi mechanism in JDK 1.6 to provide this isolation. Refer
> to 'Configuration Policy and Invocation Mode' at [1] for further
> details
>
> 2. LoginModule Creation - The Karaf implementation currently directly
> instantiates the LoginModule instance. This is similar to how normal
> usage of JAAS works in non OSGi env. However to make proper use of
> OSGi features it would be preferable to have some sort of LoginModule
> factory which is registered in OSGi Service Registry (SR) and use
> that. This allows the LoginModule provider to make better use of OSGi
> by making its implementation OSGi aware. For implementations which do
> not want to depend on OSGi the default approach would still work and
> JAAS support would manage there creation.
>
> One potential example is say a LDAPLoginModule - If I have a factory
> service then it would be possible for LDAPLoginModuleFactory to manage
> its LDAP configuration separately. It can provide its own metadata
> information for LDAP configuration which allows capturing the required
> information through Felix WebConsole with proper form support (instead
> of generic key value pairs). Also it helps is managing lifecycle - For
> example the DatabaseLoginModule factory can create a connection pool
> and provide that to LoginModule implementation.
>
> 3. Dependencies on other fwk - To make optimum use of Karaf JAAS
> support one would have to use Blueprint Runtime. In Sling we currently
> only use the Declarative Services. The proposed implementation does
> not have much dependencies and only depends on OSGi Core API and
> ConfigAdmin
>
> 4. Dynamic Realm Composition - In proposed implementation the various
> LoginModule can belong to different bundles. The JAAS support would
> use realm info from service properties (LoginModuleFactory) and config
> to determine the realm composition at runtime.
>
> Chetan Mehrotra
>
> [1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
Re: Bundle to simplify JAAS usage in OSGi
Posted by Chetan Mehrotra <ch...@gmail.com>.
> I would be interested in hearing what
>> the differences with the Karaf implementation are.
Yes I had a closer look at the JAAS support present in Karaf project.
As mentioned earlier the proposed implementation borrows from both
Karaf implementation and Stefan Vladov's proposal
Below are couple of areas where it differs from Karaf implementation
1. Global Configuration Handling - It should be possible to use OSGi
based JAAS support without affecting the Global configuration. For
example if a Sling app is deployed as war on an application server
then its usage of JAAS should not affect other applications running on
same App Server. The Karaf implementation currently replaces the
Global configuration. The proposed implementation uses the new
ConfigurationSpi mechanism in JDK 1.6 to provide this isolation. Refer
to 'Configuration Policy and Invocation Mode' at [1] for further
details
2. LoginModule Creation - The Karaf implementation currently directly
instantiates the LoginModule instance. This is similar to how normal
usage of JAAS works in non OSGi env. However to make proper use of
OSGi features it would be preferable to have some sort of LoginModule
factory which is registered in OSGi Service Registry (SR) and use
that. This allows the LoginModule provider to make better use of OSGi
by making its implementation OSGi aware. For implementations which do
not want to depend on OSGi the default approach would still work and
JAAS support would manage there creation.
One potential example is say a LDAPLoginModule - If I have a factory
service then it would be possible for LDAPLoginModuleFactory to manage
its LDAP configuration separately. It can provide its own metadata
information for LDAP configuration which allows capturing the required
information through Felix WebConsole with proper form support (instead
of generic key value pairs). Also it helps is managing lifecycle - For
example the DatabaseLoginModule factory can create a connection pool
and provide that to LoginModule implementation.
3. Dependencies on other fwk - To make optimum use of Karaf JAAS
support one would have to use Blueprint Runtime. In Sling we currently
only use the Declarative Services. The proposed implementation does
not have much dependencies and only depends on OSGi Core API and
ConfigAdmin
4. Dynamic Realm Composition - In proposed implementation the various
LoginModule can belong to different bundles. The JAAS support would
use realm info from service properties (LoginModuleFactory) and config
to determine the realm composition at runtime.
Chetan Mehrotra
[1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
Re: Bundle to simplify JAAS usage in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Sep 28, 2012 at 12:33 AM, Marcel Offermans <
marcel.offermans@luminis.nl> wrote:
> Judging from his original mail, Chetan seems to already be aware that
> there is an implementation in Karaf. I would be interested in hearing what
> the differences with the Karaf implementation are. I don't mind multiple
> implementations, that's what OSGi is all about, as long as those
> implementations have "unique features" that allow you to use them in
> situations where the other implementations work less well.
>
>
You're right, I read the original email too quickly. Interesting. The
new ConfigurationSpi object has definitely opened some doors with JDK 6.
It's a shame we still need to put the ProxyLoginModule in the boot
classpath though. I was hoping we could get rid of that.
> So perhaps Chetan can explain a bit more about this.
>
> In general I am positive towards anybody contributing and maintaining new
> functionality.
>
Of course. I really should have read the email more carefully ...
>
> Greetings, Marcel
>
> On Sep 28, 2012, at 0:01 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>
> > Fwiw, Karaf already has full JAAS support in OSGi, so it might be worth
> > looking at it instead of rewriting the wheel.
> > https://github.com/apache/karaf/tree/karaf-2.3.x/jaas
> >
> > On Thu, Sep 27, 2012 at 11:47 PM, Felix Meschberger <fmeschbe@adobe.com
> >wrote:
> >
> >> Hi,
> >>
> >> Thanks Chetan for the proposal.
> >>
> >> I find this a very interesting project and would think it would be a
> good
> >> addition to the Apache Felix portfolio.
> >>
> >> What do others think ?
> >>
> >> Disclosure: Chetan also works for Adobe and we have been discussing this
> >> before.
> >>
> >> Regards
> >> Felix
> >>
> >> Am 26.09.2012 um 15:56 schrieb Chetan Mehrotra:
> >>
> >>> I have been working on a poc to simplify usage if JAAS with Sling and
> >>> Jackrabbit. Using of JAAS within OSGi is often tricky because of
> >>> classloading issues. There has been some work done around this
> >>>
> >>> 1. JAAS support in Apache Karaf
> >>> 2. Proposal by Stefan Vladov in the presentation [1] given by him at
> >>> OSGi Community Event 2011
> >>>
> >>> Following the proposal at #2 and borrowing some ideas from Apache
> >>> Karaf I implemented a bundle which simplifies usage of JAAS within
> >>> OSGi env. It supports following features
> >>>
> >>> 1. It can work both in Standalone and AppServer deployments i.e. in
> >>> those environment where global JAAS configuration might be used by
> >>> other applications and our usage of JAAS should not affect them
> >>> 2. It enables usage of OSGi Configuration support to dynamically
> >>> configure the login modules.
> >>> 3. It allows LoginModule instances to be created via factories
> >>> registered in OSGi Service Registry
> >>> 4. It does not require the client to depend on any OSGi API
> >>> 5. It works well with the dynamic nature of the OSGi env
> >>> 6. Implementation depends only on Core OSGi API and ConfigAdmin
> >>>
> >>> Complete details are provided at [2]
> >>>
> >>> Kindly have a look at it and provide feedback!!
> >>>
> >>> Chetan Mehrotra
> >>>
> >>> [1]
> >>
> http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
> >>> [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
> >>
> >>
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > FuseSource, Integration everywhere
> > http://fusesource.com
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: Bundle to simplify JAAS usage in OSGi
Posted by Marcel Offermans <ma...@luminis.nl>.
Judging from his original mail, Chetan seems to already be aware that there is an implementation in Karaf. I would be interested in hearing what the differences with the Karaf implementation are. I don't mind multiple implementations, that's what OSGi is all about, as long as those implementations have "unique features" that allow you to use them in situations where the other implementations work less well.
So perhaps Chetan can explain a bit more about this.
In general I am positive towards anybody contributing and maintaining new functionality.
Greetings, Marcel
On Sep 28, 2012, at 0:01 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Fwiw, Karaf already has full JAAS support in OSGi, so it might be worth
> looking at it instead of rewriting the wheel.
> https://github.com/apache/karaf/tree/karaf-2.3.x/jaas
>
> On Thu, Sep 27, 2012 at 11:47 PM, Felix Meschberger <fm...@adobe.com>wrote:
>
>> Hi,
>>
>> Thanks Chetan for the proposal.
>>
>> I find this a very interesting project and would think it would be a good
>> addition to the Apache Felix portfolio.
>>
>> What do others think ?
>>
>> Disclosure: Chetan also works for Adobe and we have been discussing this
>> before.
>>
>> Regards
>> Felix
>>
>> Am 26.09.2012 um 15:56 schrieb Chetan Mehrotra:
>>
>>> I have been working on a poc to simplify usage if JAAS with Sling and
>>> Jackrabbit. Using of JAAS within OSGi is often tricky because of
>>> classloading issues. There has been some work done around this
>>>
>>> 1. JAAS support in Apache Karaf
>>> 2. Proposal by Stefan Vladov in the presentation [1] given by him at
>>> OSGi Community Event 2011
>>>
>>> Following the proposal at #2 and borrowing some ideas from Apache
>>> Karaf I implemented a bundle which simplifies usage of JAAS within
>>> OSGi env. It supports following features
>>>
>>> 1. It can work both in Standalone and AppServer deployments i.e. in
>>> those environment where global JAAS configuration might be used by
>>> other applications and our usage of JAAS should not affect them
>>> 2. It enables usage of OSGi Configuration support to dynamically
>>> configure the login modules.
>>> 3. It allows LoginModule instances to be created via factories
>>> registered in OSGi Service Registry
>>> 4. It does not require the client to depend on any OSGi API
>>> 5. It works well with the dynamic nature of the OSGi env
>>> 6. Implementation depends only on Core OSGi API and ConfigAdmin
>>>
>>> Complete details are provided at [2]
>>>
>>> Kindly have a look at it and provide feedback!!
>>>
>>> Chetan Mehrotra
>>>
>>> [1]
>> http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
>>> [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
Re: Bundle to simplify JAAS usage in OSGi
Posted by Guillaume Nodet <gn...@gmail.com>.
Fwiw, Karaf already has full JAAS support in OSGi, so it might be worth
looking at it instead of rewriting the wheel.
https://github.com/apache/karaf/tree/karaf-2.3.x/jaas
On Thu, Sep 27, 2012 at 11:47 PM, Felix Meschberger <fm...@adobe.com>wrote:
> Hi,
>
> Thanks Chetan for the proposal.
>
> I find this a very interesting project and would think it would be a good
> addition to the Apache Felix portfolio.
>
> What do others think ?
>
> Disclosure: Chetan also works for Adobe and we have been discussing this
> before.
>
> Regards
> Felix
>
> Am 26.09.2012 um 15:56 schrieb Chetan Mehrotra:
>
> > I have been working on a poc to simplify usage if JAAS with Sling and
> > Jackrabbit. Using of JAAS within OSGi is often tricky because of
> > classloading issues. There has been some work done around this
> >
> > 1. JAAS support in Apache Karaf
> > 2. Proposal by Stefan Vladov in the presentation [1] given by him at
> > OSGi Community Event 2011
> >
> > Following the proposal at #2 and borrowing some ideas from Apache
> > Karaf I implemented a bundle which simplifies usage of JAAS within
> > OSGi env. It supports following features
> >
> > 1. It can work both in Standalone and AppServer deployments i.e. in
> > those environment where global JAAS configuration might be used by
> > other applications and our usage of JAAS should not affect them
> > 2. It enables usage of OSGi Configuration support to dynamically
> > configure the login modules.
> > 3. It allows LoginModule instances to be created via factories
> > registered in OSGi Service Registry
> > 4. It does not require the client to depend on any OSGi API
> > 5. It works well with the dynamic nature of the OSGi env
> > 6. Implementation depends only on Core OSGi API and ConfigAdmin
> >
> > Complete details are provided at [2]
> >
> > Kindly have a look at it and provide feedback!!
> >
> > Chetan Mehrotra
> >
> > [1]
> http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
> > [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: Bundle to simplify JAAS usage in OSGi
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Thanks Chetan for the proposal.
I find this a very interesting project and would think it would be a good addition to the Apache Felix portfolio.
What do others think ?
Disclosure: Chetan also works for Adobe and we have been discussing this before.
Regards
Felix
Am 26.09.2012 um 15:56 schrieb Chetan Mehrotra:
> I have been working on a poc to simplify usage if JAAS with Sling and
> Jackrabbit. Using of JAAS within OSGi is often tricky because of
> classloading issues. There has been some work done around this
>
> 1. JAAS support in Apache Karaf
> 2. Proposal by Stefan Vladov in the presentation [1] given by him at
> OSGi Community Event 2011
>
> Following the proposal at #2 and borrowing some ideas from Apache
> Karaf I implemented a bundle which simplifies usage of JAAS within
> OSGi env. It supports following features
>
> 1. It can work both in Standalone and AppServer deployments i.e. in
> those environment where global JAAS configuration might be used by
> other applications and our usage of JAAS should not affect them
> 2. It enables usage of OSGi Configuration support to dynamically
> configure the login modules.
> 3. It allows LoginModule instances to be created via factories
> registered in OSGi Service Registry
> 4. It does not require the client to depend on any OSGi API
> 5. It works well with the dynamic nature of the OSGi env
> 6. Implementation depends only on Core OSGi API and ConfigAdmin
>
> Complete details are provided at [2]
>
> Kindly have a look at it and provide feedback!!
>
> Chetan Mehrotra
>
> [1] http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
> [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
Re: Bundle to simplify JAAS usage in OSGi
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 07.10.2012 um 18:33 schrieb Marcel Offermans:
> On Oct 7, 2012, at 18:24 PM, Felix Meschberger <fm...@adobe.com> wrote:
>
>> Thanks for comments so far and to Chetan for offering this bundle.
>>
>> Am 07.10.2012 um 14:08 schrieb Marcel Offermans:
>>
>>> On Oct 7, 2012, at 10:23 AM, Chetan Mehrotra <ch...@gmail.com> wrote:
>>>
>>>> So what should be the next step here?.
>>>>
>>>> Should I create a JIRA issue and attach the source code there or more
>>>> discussions/details are required on the approach taken.
>>>
>>> As far as I'm concerned, please create a JIRA issue and attach the code there.
>>>
>>> Since you're not yet an Apache committer (right?) we probably also need a software grant for this code. I'm sure Felix can help you with that.
>>
>> Though Chetan is now an Apache committer (to the Jackrabbit project) and his ICLA is on file I think this is a substantial contribution from the outside and we should do the full IP Clearance process as documented in [1].
>
> That's what I thought, and did, until recently, when Roy Fielding posted a statement on the incubator mailing list [3] stating that we basically don't need all of that stuff below if someone already is a committer.
I am not really sure whether this is "just about any Apache committer" or "a committer to the project in question". Trying to wade through the discussions I would understand it as more like "committer to the project in question".
I would prefer to go the IP Clearance route in this case.
Regards
Felix
>
>> This means:
>> - We need the JIRA issue with the code attached and checksums in a comment
>> - A Software Grant faxed [2]
>> - A vote by the project
>> - and the Incubator form and clearance
>>
>> I can drive this contribution.
>>
>> Thanks again to Chetan for providing this.
>>
>> Regards
>> Felix
>>
>> [1] http://incubator.apache.org/ip-clearance/index.html
>> [2] http://www.apache.org/licenses/software-grant.txt
>
> [3] http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CD9228733-CBBB-45DA-ABED-EE2AB12EE53B%40gbiv.com%3E
Re: Bundle to simplify JAAS usage in OSGi
Posted by Marcel Offermans <ma...@luminis.nl>.
On Oct 7, 2012, at 18:24 PM, Felix Meschberger <fm...@adobe.com> wrote:
> Thanks for comments so far and to Chetan for offering this bundle.
>
> Am 07.10.2012 um 14:08 schrieb Marcel Offermans:
>
>> On Oct 7, 2012, at 10:23 AM, Chetan Mehrotra <ch...@gmail.com> wrote:
>>
>>> So what should be the next step here?.
>>>
>>> Should I create a JIRA issue and attach the source code there or more
>>> discussions/details are required on the approach taken.
>>
>> As far as I'm concerned, please create a JIRA issue and attach the code there.
>>
>> Since you're not yet an Apache committer (right?) we probably also need a software grant for this code. I'm sure Felix can help you with that.
>
> Though Chetan is now an Apache committer (to the Jackrabbit project) and his ICLA is on file I think this is a substantial contribution from the outside and we should do the full IP Clearance process as documented in [1].
That's what I thought, and did, until recently, when Roy Fielding posted a statement on the incubator mailing list [3] stating that we basically don't need all of that stuff below if someone already is a committer.
> This means:
> - We need the JIRA issue with the code attached and checksums in a comment
> - A Software Grant faxed [2]
> - A vote by the project
> - and the Incubator form and clearance
>
> I can drive this contribution.
>
> Thanks again to Chetan for providing this.
>
> Regards
> Felix
>
> [1] http://incubator.apache.org/ip-clearance/index.html
> [2] http://www.apache.org/licenses/software-grant.txt
[3] http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3CD9228733-CBBB-45DA-ABED-EE2AB12EE53B%40gbiv.com%3E
Re: Bundle to simplify JAAS usage in OSGi
Posted by Felix Meschberger <fm...@adobe.com>.
Thanks Chetan.
I am going to start the acceptance vote now.
Regards
Felix
Am 10.10.2012 um 07:32 schrieb Chetan Mehrotra:
>> This means:
>> - We need the JIRA issue with the code attached and checksums in a comment
>
> Created JIRA issue FELIX-3705 with code and checksum attached
>
> Chetan Mehrotra
Re: Bundle to simplify JAAS usage in OSGi
Posted by Chetan Mehrotra <ch...@gmail.com>.
> This means:
> - We need the JIRA issue with the code attached and checksums in a comment
Created JIRA issue FELIX-3705 with code and checksum attached
Chetan Mehrotra
Re: Bundle to simplify JAAS usage in OSGi
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Thanks for comments so far and to Chetan for offering this bundle.
Am 07.10.2012 um 14:08 schrieb Marcel Offermans:
> On Oct 7, 2012, at 10:23 AM, Chetan Mehrotra <ch...@gmail.com> wrote:
>
>> So what should be the next step here?.
>>
>> Should I create a JIRA issue and attach the source code there or more
>> discussions/details are required on the approach taken.
>
> As far as I'm concerned, please create a JIRA issue and attach the code there.
>
> Since you're not yet an Apache committer (right?) we probably also need a software grant for this code. I'm sure Felix can help you with that.
Though Chetan is now an Apache committer (to the Jackrabbit project) and his ICLA is on file I think this is a substantial contribution from the outside and we should do the full IP Clearance process as documented in [1].
This means:
- We need the JIRA issue with the code attached and checksums in a comment
- A Software Grant faxed [2]
- A vote by the project
- and the Incubator form and clearance
I can drive this contribution.
Thanks again to Chetan for providing this.
Regards
Felix
[1] http://incubator.apache.org/ip-clearance/index.html
[2] http://www.apache.org/licenses/software-grant.txt
Re: Bundle to simplify JAAS usage in OSGi
Posted by Marcel Offermans <ma...@luminis.nl>.
On Oct 7, 2012, at 10:23 AM, Chetan Mehrotra <ch...@gmail.com> wrote:
> So what should be the next step here?.
>
> Should I create a JIRA issue and attach the source code there or more
> discussions/details are required on the approach taken.
As far as I'm concerned, please create a JIRA issue and attach the code there.
Since you're not yet an Apache committer (right?) we probably also need a software grant for this code. I'm sure Felix can help you with that.
Greetings, Marcel
Re: Bundle to simplify JAAS usage in OSGi
Posted by Chetan Mehrotra <ch...@gmail.com>.
So what should be the next step here?.
Should I create a JIRA issue and attach the source code there or more
discussions/details are required on the approach taken.
Chetan Mehrotra
Re: Bundle to simplify JAAS usage in OSGi
Posted by Reto Bachmann-Gmür <re...@wymiwyg.com>.
On Fri, Sep 28, 2012 at 1:27 PM, Chetan Mehrotra
<ch...@gmail.com>wrote:
> Hi Reto,
>
> > Could you help me understand what using your bundle would imply. Is this
> a
> > regular bundle that can just be added to any OSGi application ore are
> some
> > special tweaks needed starting/configuring the platform?
>
> I have added a usage section [1] which provides required steps. Hope
> that helps. Also let me know if you require more details
>
> Chetan Mehrotra
> [1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi#wiki-usage
Thanks! The bundle looks good and can be installed in stanbol, from the
documentation the existing stanbol api could be migrated to provide a
LoginModule. It would be great if it could soon be available either as
felix component or as independent project (as long as it gets into maven
central).
Reto
>
>
>
> On Fri, Sep 28, 2012 at 4:40 AM, Reto Bachmann-Gmür <re...@apache.org>
> wrote:
> > Hi Chetan
> >
> > Recently we have added security to Stanbol so that it can be run with a
> > security manager in place. Regarding authentication of HTTP clients for
> now
> > the providers must implement our own service interface [1]. The
> > authentication providers authenticate a user before subsequent processing
> > of the request is executed as the authenticated subject.
> >
> > Could you help me understand what using your bundle would imply. Is this
> a
> > regular bundle that can just be added to any OSGi application ore are
> some
> > special tweaks needed starting/configuring the platform?
> >
> > Cheers,
> > Reto
> >
> >
> > 1.
> >
> http://svn.apache.org/viewvc/stanbol/trunk/commons/security/src/main/java/org/apache/stanbol/commons/security/auth/AuthenticationMethod.java?view=markup
> >
> > On Wed, Sep 26, 2012 at 3:56 PM, Chetan Mehrotra
> > <ch...@gmail.com>wrote:
> >
> >> I have been working on a poc to simplify usage if JAAS with Sling and
> >> Jackrabbit. Using of JAAS within OSGi is often tricky because of
> >> classloading issues. There has been some work done around this
> >>
> >> 1. JAAS support in Apache Karaf
> >> 2. Proposal by Stefan Vladov in the presentation [1] given by him at
> >> OSGi Community Event 2011
> >>
> >> Following the proposal at #2 and borrowing some ideas from Apache
> >> Karaf I implemented a bundle which simplifies usage of JAAS within
> >> OSGi env. It supports following features
> >>
> >> 1. It can work both in Standalone and AppServer deployments i.e. in
> >> those environment where global JAAS configuration might be used by
> >> other applications and our usage of JAAS should not affect them
> >> 2. It enables usage of OSGi Configuration support to dynamically
> >> configure the login modules.
> >> 3. It allows LoginModule instances to be created via factories
> >> registered in OSGi Service Registry
> >> 4. It does not require the client to depend on any OSGi API
> >> 5. It works well with the dynamic nature of the OSGi env
> >> 6. Implementation depends only on Core OSGi API and ConfigAdmin
> >>
> >> Complete details are provided at [2]
> >>
> >> Kindly have a look at it and provide feedback!!
> >>
> >> Chetan Mehrotra
> >>
> >> [1]
> >>
> http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
> >> [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
> >>
>
Re: Bundle to simplify JAAS usage in OSGi
Posted by Chetan Mehrotra <ch...@gmail.com>.
Hi Reto,
> Could you help me understand what using your bundle would imply. Is this a
> regular bundle that can just be added to any OSGi application ore are some
> special tweaks needed starting/configuring the platform?
I have added a usage section [1] which provides required steps. Hope
that helps. Also let me know if you require more details
Chetan Mehrotra
[1] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi#wiki-usage
On Fri, Sep 28, 2012 at 4:40 AM, Reto Bachmann-Gmür <re...@apache.org> wrote:
> Hi Chetan
>
> Recently we have added security to Stanbol so that it can be run with a
> security manager in place. Regarding authentication of HTTP clients for now
> the providers must implement our own service interface [1]. The
> authentication providers authenticate a user before subsequent processing
> of the request is executed as the authenticated subject.
>
> Could you help me understand what using your bundle would imply. Is this a
> regular bundle that can just be added to any OSGi application ore are some
> special tweaks needed starting/configuring the platform?
>
> Cheers,
> Reto
>
>
> 1.
> http://svn.apache.org/viewvc/stanbol/trunk/commons/security/src/main/java/org/apache/stanbol/commons/security/auth/AuthenticationMethod.java?view=markup
>
> On Wed, Sep 26, 2012 at 3:56 PM, Chetan Mehrotra
> <ch...@gmail.com>wrote:
>
>> I have been working on a poc to simplify usage if JAAS with Sling and
>> Jackrabbit. Using of JAAS within OSGi is often tricky because of
>> classloading issues. There has been some work done around this
>>
>> 1. JAAS support in Apache Karaf
>> 2. Proposal by Stefan Vladov in the presentation [1] given by him at
>> OSGi Community Event 2011
>>
>> Following the proposal at #2 and borrowing some ideas from Apache
>> Karaf I implemented a bundle which simplifies usage of JAAS within
>> OSGi env. It supports following features
>>
>> 1. It can work both in Standalone and AppServer deployments i.e. in
>> those environment where global JAAS configuration might be used by
>> other applications and our usage of JAAS should not affect them
>> 2. It enables usage of OSGi Configuration support to dynamically
>> configure the login modules.
>> 3. It allows LoginModule instances to be created via factories
>> registered in OSGi Service Registry
>> 4. It does not require the client to depend on any OSGi API
>> 5. It works well with the dynamic nature of the OSGi env
>> 6. Implementation depends only on Core OSGi API and ConfigAdmin
>>
>> Complete details are provided at [2]
>>
>> Kindly have a look at it and provide feedback!!
>>
>> Chetan Mehrotra
>>
>> [1]
>> http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
>> [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
>>
Re: Bundle to simplify JAAS usage in OSGi
Posted by Reto Bachmann-Gmür <re...@apache.org>.
Hi Chetan
Recently we have added security to Stanbol so that it can be run with a
security manager in place. Regarding authentication of HTTP clients for now
the providers must implement our own service interface [1]. The
authentication providers authenticate a user before subsequent processing
of the request is executed as the authenticated subject.
Could you help me understand what using your bundle would imply. Is this a
regular bundle that can just be added to any OSGi application ore are some
special tweaks needed starting/configuring the platform?
Cheers,
Reto
1.
http://svn.apache.org/viewvc/stanbol/trunk/commons/security/src/main/java/org/apache/stanbol/commons/security/auth/AuthenticationMethod.java?view=markup
On Wed, Sep 26, 2012 at 3:56 PM, Chetan Mehrotra
<ch...@gmail.com>wrote:
> I have been working on a poc to simplify usage if JAAS with Sling and
> Jackrabbit. Using of JAAS within OSGi is often tricky because of
> classloading issues. There has been some work done around this
>
> 1. JAAS support in Apache Karaf
> 2. Proposal by Stefan Vladov in the presentation [1] given by him at
> OSGi Community Event 2011
>
> Following the proposal at #2 and borrowing some ideas from Apache
> Karaf I implemented a bundle which simplifies usage of JAAS within
> OSGi env. It supports following features
>
> 1. It can work both in Standalone and AppServer deployments i.e. in
> those environment where global JAAS configuration might be used by
> other applications and our usage of JAAS should not affect them
> 2. It enables usage of OSGi Configuration support to dynamically
> configure the login modules.
> 3. It allows LoginModule instances to be created via factories
> registered in OSGi Service Registry
> 4. It does not require the client to depend on any OSGi API
> 5. It works well with the dynamic nature of the OSGi env
> 6. Implementation depends only on Core OSGi API and ConfigAdmin
>
> Complete details are provided at [2]
>
> Kindly have a look at it and provide feedback!!
>
> Chetan Mehrotra
>
> [1]
> http://www.slideshare.net/mfrancis/common-security-services-consolidation-patterns-for-legacy-components-stefan-vladov
> [2] https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
>