I've opened
http://forge.ow2.org/tracker/index.php?func=detail&aid=316321&group_id=23&atid=350023
with a patch that uses bnd to create proper osgi metadata so repackaging asm
will be unnecessary. Possibly comments indicating this would be useful would
help the idea gain traction.
thanks
david
You are of course right Andreas. I just wanted to mention that moving to
Shiro instead of sticking with JAAS might make the implementation a lot
easier and more flexible.
/Bengt
2012/1/30 Andreas Pieber
> Shiro will also work with apache wicket quite fine. But I think we should
> rather fixate
Shiro will also work with apache wicket quite fine. But I think we should
rather fixate first what we want to do and then decide how to do this.
Kind regards,
Andreas
On Jan 30, 2012 6:45 PM, "Bengt Rodehav" wrote:
> I use Apache Shiro for both authentication and authorisation. JAAS is far
> fro
I use Apache Shiro for both authentication and authorisation. JAAS is far
from ideal when it comes to complex authorisation schemes. The command tree
that you are talking about could be mapped using permissions in Shiro. You
would then create roles as needed - both fine grained and coarse grained
(
I think a typical system for authorization would have resource level
rights like "bundle:install" and high level roles that each have a set
of those rights.
This works of course but is a lot of configuration work. So we should be
sure we really need that before we implement it.
Another thing i
One big use case I've seen is when you have a production environment
and you want to allow people to connect to *see* things, but obviously
not everybody to make changes. And such roles should not have to be
modified when you install new bundles. Which means commands have to
be assigned into one
Then, we're talking more about authorization than roles, which makes
sense to me.
But we should not mix both. So what you're wiring is more command
level authorization, but we should not use roles to explicit those.
Defining a role per command is just not scalable and new commands
won't be able t
Guillaume,
My goal is to provide fine grained access control. Not only a read or write
access but also domain specific, just imagine that you have a production
installation and developers have read only access to Apache Camel metrics, JMS
Queues and OSGi bundles but also have write access to con
The Karaf team is pleased to announce the availability of Karaf Cellar
2.2.3.
This release of Apache Karaf Cellar is based off of the 2.2.x series
branch, representing an update to Apache Karaf Cellar 2.2.2. It contains
bug fixes identified in the prior release, and introduces improvements
in
As I explained, I'm not sure which use case you're trying to achieve,
but that does not address the only use case I've heard about, which is
to be able to have profiles that are read-only and profiles that have
read-write access.
2012/1/30 Łukasz Dywicki :
> Hey guys,
> I am about to complete some
Hey guys,
I am about to complete some changes in webconsole.
Currently the schema is following.
To view list of bundles you need a osgi-list role.
To install bundle you need a osgi-install role assigned and so on.
To execute all osgi related operations, read or write, you need a "osgi" role.
If
Hi all,
the vote has passed with the following result:
+1 (binding): Ioannis Canellos, Jean-Baptiste Onofré, Jamie Goodyear,
Gert Vanthienen, Andreas Pieber
+1 (non-binding): Johan Edstrom
No other vote.
Thanks all for your vote.
I'm promoting the artifacts on the Central, and updating Jira
12 matches
Mail list logo