You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by kuvalda <pe...@mail.ru> on 2015/04/27 20:00:01 UTC
Re: Security in Module
Hi, Christian!
I tried your blueprint-authz bundle to to authorize in OSGi services and
found out in its code, that SecurityAnotationParser parses beans, so looks
for annotations in class. But in runtime AuthorizationInterceptor looks for
annotations in called method's declaring class.
As an OSGi service is an interface, we can get such a situation, that method
of a class would require athorization, but could not get it, if service's
interface would not be annotated with @RolesAlowed. It's a code example
below:
public interface EchoService {
//@RolesAllowed("admin")
public String echo(String message);
}
public class SimpleEchoService implements EchoService {
@RolesAllowed("admin")
@Override
public String echo(String message) {
String result = message;
return result;
}
}
@Command(scope = "kb", name = "echo")
public class EchoCommand extends OsgiCommandSupport {
private EchoService echoService;
public EchoService getEchoService() {
return echoService;
}
public void setEchoService(EchoService echoService) {
this.echoService = echoService;
}
@Argument(index = 0, name = "message", required = true, multiValued =
false)
private String message;
@Override
protected Object doExecute() throws Exception {
return echoService.echo(message);
}
}
Calling "echo" command in karaf console in this case we will get an error
message with empty roles' list "Method call interface
biz.lorien.umrp.kb.properties.EchoService.echo denied. Roles allowed are
[]".
And it's OK with uncommented annotation @RolesAllowed("admin") in
EchoService interface.
I think, it's not the best way to duplicate annotations both in interface
and implementing class.
Perhaps, it's my incorrect use of blueprint-authz?
What do you think about it?
Thanks in advance!
Pavel
cschneider wrote
> There is one more thing you should look into. Quite often you will need
> the authentication result in a place different from the place where you
> do the authentication.
> Passing the subject around is not very effective.
>
> Luckily there is a quite unknown way in JAAS to do this:
>
> AccessControlContext acc = AccessController.getContext();
> Subject subject = Subject.getSubject(acc);
>
> This allows to get the subject at any place in your code.
>
> An even more convenient way if you use blueprint is to authorize based
> on security annotations.
> See the blueprint-auhtz module:
> https://fisheye6.atlassian.com/browse/~br=trunk/aries/trunk/blueprint/blueprint-authz
-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040001.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Security in Module
Posted by kuvalda <pe...@mail.ru>.
Thanks, Christian
Issue is created.
https://issues.apache.org/jira/browse/ARIES-1316
<https://issues.apache.org/jira/browse/ARIES-1316>
cschneider wrote
> Hi Pavel,
>
> the link is
> https://issues.apache.org/jira/browse/ARIES
>
> you can find this link on the aries website in
> http://aries.apache.org/community/gettinginvolved.html too.
>
> Christian
-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040085.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Security in Module
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Pavel,
the link is
https://issues.apache.org/jira/browse/ARIES
you can find this link on the aries website in
http://aries.apache.org/community/gettinginvolved.html too.
Christian
On 29.04.2015 16:39, kuvalda wrote:
> Really, I have some problem with it.
> Could you provide some link, where I can do it?
>
>
> cschneider wrote
>> Hmm .. I think this is a bug then.
>> Probably we should always look in both the interface and the class for
>> the annotations. Can you open an issue for this ?
>
>
>
>
> -----
> Pavel
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040077.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Security in Module
Posted by kuvalda <pe...@mail.ru>.
Really, I have some problem with it.
Could you provide some link, where I can do it?
cschneider wrote
> Hmm .. I think this is a bug then.
> Probably we should always look in both the interface and the class for
> the annotations. Can you open an issue for this ?
-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040077.html
Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Security in Module
Posted by Christian Schneider <ch...@die-schneider.net>.
Hmm .. I think this is a bug then.
Probably we should always look in both the interface and the class for
the annotations. Can you open an issue for this ?
Christian
On 27.04.2015 20:00, kuvalda wrote:
> Hi, Christian!
> I tried your blueprint-authz bundle to to authorize in OSGi services and
> found out in its code, that SecurityAnotationParser parses beans, so looks
> for annotations in class. But in runtime AuthorizationInterceptor looks for
> annotations in called method's declaring class.
> As an OSGi service is an interface, we can get such a situation, that method
> of a class would require athorization, but could not get it, if service's
> interface would not be annotated with @RolesAlowed. It's a code example
> below:
>
> public interface EchoService {
> //@RolesAllowed("admin")
> public String echo(String message);
> }
>
> public class SimpleEchoService implements EchoService {
> @RolesAllowed("admin")
> @Override
> public String echo(String message) {
> String result = message;
> return result;
> }
>
> }
>
> @Command(scope = "kb", name = "echo")
> public class EchoCommand extends OsgiCommandSupport {
> private EchoService echoService;
> public EchoService getEchoService() {
> return echoService;
> }
> public void setEchoService(EchoService echoService) {
> this.echoService = echoService;
> }
> @Argument(index = 0, name = "message", required = true, multiValued =
> false)
> private String message;
> @Override
> protected Object doExecute() throws Exception {
> return echoService.echo(message);
> }
> }
>
> Calling "echo" command in karaf console in this case we will get an error
> message with empty roles' list "Method call interface
> biz.lorien.umrp.kb.properties.EchoService.echo denied. Roles allowed are
> []".
> And it's OK with uncommented annotation @RolesAllowed("admin") in
> EchoService interface.
>
> I think, it's not the best way to duplicate annotations both in interface
> and implementing class.
> Perhaps, it's my incorrect use of blueprint-authz?
> What do you think about it?
>
> Thanks in advance!
> Pavel
>
>
> cschneider wrote
>> There is one more thing you should look into. Quite often you will need
>> the authentication result in a place different from the place where you
>> do the authentication.
>> Passing the subject around is not very effective.
>>
>> Luckily there is a quite unknown way in JAAS to do this:
>>
>> AccessControlContext acc = AccessController.getContext();
>> Subject subject = Subject.getSubject(acc);
>>
>> This allows to get the subject at any place in your code.
>>
>> An even more convenient way if you use blueprint is to authorize based
>> on security annotations.
>> See the blueprint-auhtz module:
>> https://fisheye6.atlassian.com/browse/~br=trunk/aries/trunk/blueprint/blueprint-authz
>
>
>
>
> -----
> Pavel
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040001.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com