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.
