.@gmail.com
> >>>>>>> wrote:
> >>>>>>
> >>>>>>> I am in favor of a private interface that has a default
> >> implementation,
> >>>>>>> and one that shiro could provide.
> >>>>>&g
t;>>>>>> public interface SubjectContext {
>>>>>>>Subject getCurrentSubject();
>>>>>>> }
>>>>>>>
>>>>>>> Note: when utilizing Subject.doAs(), as karaf commands do, the
>>>> "cur
gt; My feeling here is that there is a "SubjectContextProvider" SPI that
> >>>>> needs to be 1:N within a Karaf implementation to obtain a subject.
> >> Within
> >>>>> Camel, as an example, the current message exchange holds a subject
> as a
&
use that would be incompatible and require much more work. It's a
>>>>>> tradeoff I guess and I'm currently not yet convinced that it's really
>>>>>> needed, but as I said, I don't have any real objection at this point.
>>>>>>
have any real objection at this point.
> >>>> But what I'm working on is a real need, so we can revisit the
> underlying
> >>>> implementation later, that's not really a problem as the interface
> would
> >>>> not even have to change, while we can't
'm working on is a real need, so we can revisit the underlying
>>>> implementation later, that's not really a problem as the interface would
>>>> not even have to change, while we can't really change the underlying
>>>> security implementati
n revisit the underlying
>> > implementation later, that's not really a problem as the interface would
>> > not even have to change, while we can't really change the underlying
>> > security implementation in a minor release such as 2.3 or 2.4 or just
>> > befo
at 9:58 PM, Andrei Pozolotin <
> > andrei.pozolo...@gmail.com> wrote:
> >
> >> in this case, why not drop jaas altogether,
> >> and use shiro everywhere in karaf instead of jaas,
> >> for everything, not just for "shell commands"?
> >>
> >> -
just
> before releasing 3.0 ...
>
> On Wed, Oct 31, 2012 at 9:58 PM, Andrei Pozolotin <
> andrei.pozolo...@gmail.com> wrote:
>
>> in this case, why not drop jaas altogether,
>> and use shiro everywhere in karaf instead of jaas,
>> for everything, not just for "shell
M, Andrei Pozolotin <
andrei.pozolo...@gmail.com> wrote:
> in this case, why not drop jaas altogether,
> and use shiro everywhere in karaf instead of jaas,
> for everything, not just for "shell commands"?
>
> ---- Original Message
> Subject: Re: Securing shell
in this case, why not drop jaas altogether,
and use shiro everywhere in karaf instead of jaas,
for everything, not just for "shell commands"?
Original Message
Subject: Re: Securing shell commands
From: Guillaume Nodet
To: dev@karaf.apache.org
Date: Wed 31 Oct 2012 0
ocs.oracle.com/javase/6/docs/api/java/security/Principal.html
>
> ?
>
> ---- Original Message
> Subject: Re: Securing shell commands
> From: Achim Nierbeck
> To: dev@karaf.apache.org
> Date: Tue 30 Oct 2012 04:27:40 PM CDT
> > Hi,
> &g
I mean why
void checkPermission(List principals, String permission);
is not using
http://docs.oracle.com/javase/6/docs/api/java/security/Principal.html
?
Original Message
Subject: Re: Securing shell commands
From: Achim Nierbeck
To: dev@karaf.apache.org
Date: Tue 30 Oct
Achim
2012/10/30 Andrei Pozolotin :
> and
> http://docs.oracle.com/javase/6/docs/api/java/security/Principal.html
>
> is wrong, because ...?
>
>
> Original Message ----
> Subject: Re: Securing shell commands
> From: Guillaume Nodet
> To: dev@karaf.apache.o
and
http://docs.oracle.com/javase/6/docs/api/java/security/Principal.html
is wrong, because ...?
Original Message
Subject: Re: Securing shell commands
From: Guillaume Nodet
To: dev@karaf.apache.org
Date: Tue 30 Oct 2012 03:20:48 PM CDT
> Permissions in JAAS can't be u
t; ---- Original Message
> Subject: Re: Securing shell commands
> From: Guillaume Nodet
> To: dev@karaf.apache.org, k...@westerfeld.com
> Date: Tue 30 Oct 2012 11:03:14 AM CDT
>
> So what about a service defined like the following:
>
> public interface Authorizati
: Securing shell commands
From: Guillaume Nodet
To: dev@karaf.apache.org, k...@westerfeld.com
Date: Tue 30 Oct 2012 11:03:14 AM CDT
> So what about a service defined like the following:
>
> public interface AuthorizationService {
>
> List getPrincipals(Subject subject);
>
>
to me it was just a reminder: "all things touching on JAAS should use
clearly defined TCCL / classloader pattern or provider contract or etc."
Original Message
Subject: Re: Securing shell commands
From: Guillaume Nodet
To: Andrei Pozolotin
Cc: dev@karaf.apache.org
Da
How does that relate to authorization ?
On Tue, Oct 30, 2012 at 6:17 PM, Andrei Pozolotin <
andrei.pozolo...@gmail.com> wrote:
> few more concerns/ideas
>
> https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
>
>
> Original Message ----
> Subject: Sec
few more concerns/ideas
https://github.com/chetanmeh/c/wiki/JAAS-in-OSGi
Original Message
Subject: Securing shell commands
From: Guillaume Nodet
To: dev@karaf.apache.org
Date: Tue 30 Oct 2012 06:20:25 AM CDT
> I've worked last week on a solution for KARAF-979, i.e. pro
yes on both.
On Tue, Oct 30, 2012 at 5:05 PM, Claus Ibsen wrote:
> Hi
>
> What is the difference between the void and the boolean methods?
> Would the void throw any exceptions if check fails, or how is that to
> be understood?
>
> And I assume javadoc is added to the interface + methods.
>
>
>
Hi
What is the difference between the void and the boolean methods?
Would the void throw any exceptions if check fails, or how is that to
be understood?
And I assume javadoc is added to the interface + methods.
On Tue, Oct 30, 2012 at 5:03 PM, Guillaume Nodet wrote:
> So what about a service d
So what about a service defined like the following:
public interface AuthorizationService {
List getPrincipals(Subject subject);
void checkPermission(Subject subject, String permission);
boolean isPermitted(Subject subject, String permission);
void checkRole(Subject subject, St
Ok, that totally makes sense to me.
Let me enhance the interface to provide more non jaas tied methods and get
back to this list.
On Tue, Oct 30, 2012 at 3:29 PM, Kurt Westerfeld
wrote:
> I was thinking of Shiro as a provider for the authorization engine, not as
> the actual interfaces.
>
> I act
I was thinking of Shiro as a provider for the authorization engine, not as
the actual interfaces.
I actually think the container should provide a default implementation for
security concerns. If you look at JEE, there are definitely standards
there, which haven't worked out perfectly, but at leas
Thx for the feedback, Kurt.
I've looked at Shiro when working on this feature. Actually, the
interface, and even a class I use for the implementation come from shiro.
The reason why I discarded reusing shiro directly is mainly that it does
not provide the features we need. However, that's clearl
I think the problem you find as you go down this route, is not that this
checkPermission/isPermitted won't work for this command interface, but that
there is a more fundamental problem across Karaf-based apps and enterprise apps
in general, in that a javax.security.auth.Subject may actually be a
Well, since there is no standardized approach for securing applications
within OSGi, I think your approach is as good as any other. Playing with
your ideas a little bit in my head I would say that it should basically
works for all our (Karaf) requirements. Therefore --> good work and +1 :-)
Kind r
OK, no worries. Your introduction looks good to me.
Regards
JB
On 10/30/2012 01:06 PM, Guillaume Nodet wrote:
It's just on my laptop for now, but I can commit anywhere, either github
for other people to have a look or any karaf branch.
On Tue, Oct 30, 2012 at 1:04 PM, Jean-Baptiste Onofré wrot
It's just on my laptop for now, but I can commit anywhere, either github
for other people to have a look or any karaf branch.
On Tue, Oct 30, 2012 at 1:04 PM, Jean-Baptiste Onofré wrote:
> You don't put it on your github fork (it's what I understood) ?
>
> Regards
> JB
>
>
> On 10/30/2012 01:01 P
You don't put it on your github fork (it's what I understood) ?
Regards
JB
On 10/30/2012 01:01 PM, Guillaume Nodet wrote:
Well, I haven't committed anything yet, I was looking for feedback before
...
On Tue, Oct 30, 2012 at 12:25 PM, Jean-Baptiste Onofré wrote:
Thanks for the update Guillaum
Well, I haven't committed anything yet, I was looking for feedback before
...
On Tue, Oct 30, 2012 at 12:25 PM, Jean-Baptiste Onofré wrote:
> Thanks for the update Guillaume and great job !
>
> I gonna experiment (in combination with sub-shell) and extend to JMX, but
> it looks very good.
>
> Tha
Thanks for the update Guillaume and great job !
I gonna experiment (in combination with sub-shell) and extend to JMX,
but it looks very good.
Thanks again,
Regards
JB
On 10/30/2012 12:20 PM, Guillaume Nodet wrote:
I've worked last week on a solution for KARAF-979, i.e. providing a way to
sec
I've worked last week on a solution for KARAF-979, i.e. providing a way to
secure shell commands.
What I came up with is the following.
A new simple authentication service, exposed as an OSGi service with the
following interface
public interface AuthorizationService {
void checkPermission(Su
34 matches
Mail list logo
