You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Andrew Phillips <an...@gmail.com> on 2015/03/26 01:47:48 UTC

Security in Module

I am hoping to utilize the Karaf security module in a bundle of mine.   What is the best way, if there is an example, of authenticating a user if i have a user name and password and getting back the roles so i can use the built in security module?

I appreciate the help.   Love the product, I am using Karaf 3.0.3.


Thanks!
Andy P



Re: Security in Module

Posted by ellirael <el...@mail.ru>.
Any info from Achym?



--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040555.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Security in Module

Posted by Christian Schneider <ch...@die-schneider.net>.
Jaas only sets the context inside the PriviledgedAction call.
So after the call it is normal that you can not get the context anymore. 
If you try AccessController.getContext(); inside the run() method it 
should work.

The problem is that the way the HttpContex-authenticated works you can 
not call the rest of the code inside the Priviledged Action. So honestly 
I am not sure
how to approach this.

Christian


On 25.06.2015 12:50, kuvalda wrote:
> Hi, Christian!
> I've found a post about this problem here.
> http://stackoverflow.com/questions/26592821/configure-authentication-for-servlets-in-osgi
> <http://stackoverflow.com/questions/26592821/configure-authentication-for-servlets-in-osgi>
>
> Achim answered here, that the only way to authenticate in Servlets,
> registered by OSGi way (whiteboard in our case), is to use specific
> HttpContext with Servlet.
> I tried to use AuthHttpContext from Pax Web Samples with modified method for
> JAAS Login:
>
> protected boolean authenticated(HttpServletRequest request) {
> 	request.setAttribute(AUTHENTICATION_TYPE, HttpServletRequest.BASIC_AUTH);
> 	try {
> 		LoginContext lc = new LoginContext(realm,
> 				new BasicAuthCallbackHandler(
> 						request.getHeader("Authorization")));
> 		lc.login();
> 		Subject.doAs(lc.getSubject(), new PrivilegedAction<Void>() {
> 			@Override
> 			public Void run() {
> 				return null;
> 			}
> 		});
> 		AccessControlContext acc = AccessController.getContext();
> 		Subject subject = Subject.getSubject(acc);
> 		System.out.println(subject == null);
> 		request.setAttribute(REMOTE_USER, "test");
> 		return true;
> 	} catch (LoginException e) {
> 		return false;
> 	}
> }
>
> There's a mock PrivilegedAction, doing notihng.
> But subject is null again in AccessController.getContext() even after
> Subject.doAs().
>
> What's the problem can be?
>
> Thanks in advance!
> Pavel
>
>
> cschneider wrote
>> A JAAS login is not enough. You also need to call subject.doAs(handler);
>> Inside this call the AccessControlContext will then contain your subject.
>>
>> For web there should be a better way to establish a JAAS context. Maybe
>> you can make pax web or jetty check the authentication and
>> already establish a JAAS context for you. I forwarded to Achim. He might
>> know if that works.
>>
>> Christian
>
>
>
>
> -----
> Pavel
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4041072.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>.
Hi, Christian!
I've found a post about this problem here.
http://stackoverflow.com/questions/26592821/configure-authentication-for-servlets-in-osgi
<http://stackoverflow.com/questions/26592821/configure-authentication-for-servlets-in-osgi>  

Achim answered here, that the only way to authenticate in Servlets,
registered by OSGi way (whiteboard in our case), is to use specific
HttpContext with Servlet.
I tried to use AuthHttpContext from Pax Web Samples with modified method for
JAAS Login:

protected boolean authenticated(HttpServletRequest request) {
	request.setAttribute(AUTHENTICATION_TYPE, HttpServletRequest.BASIC_AUTH);
	try {
		LoginContext lc = new LoginContext(realm,
				new BasicAuthCallbackHandler(
						request.getHeader("Authorization")));
		lc.login();
		Subject.doAs(lc.getSubject(), new PrivilegedAction<Void>() {
			@Override
			public Void run() {
				return null;
			}
		});
		AccessControlContext acc = AccessController.getContext();
		Subject subject = Subject.getSubject(acc);
		System.out.println(subject == null);
		request.setAttribute(REMOTE_USER, "test");
		return true;
	} catch (LoginException e) {
		return false;
	}
}

There's a mock PrivilegedAction, doing notihng.
But subject is null again in AccessController.getContext() even after
Subject.doAs().

What's the problem can be?

Thanks in advance!
Pavel


cschneider wrote
> A JAAS login is not enough. You also need to call subject.doAs(handler);
> Inside this call the AccessControlContext will then contain your subject.
> 
> For web there should be a better way to establish a JAAS context. Maybe 
> you can make pax web or jetty check the authentication and
> already establish a JAAS context for you. I forwarded to Achim. He might 
> know if that works.
> 
> Christian





-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4041072.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Security in Module

Posted by ellirael <el...@mail.ru>.
Christian, any news on a proplem? I'm trying to use embedded security
solution. Or you'd advice to try shiro? Any problems is known with shiro?



--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4041046.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Security in Module

Posted by kuvalda <pe...@mail.ru>.
015-06-17 13:39:16,639 | WARN  | qtp1776346584-58 | AbstractHttpConnection          
| 79 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.15.v20140411 | /
java.lang.RuntimeException: java.lang.ClassNotFoundException:
org.eclipse.jetty.plus.jaas.JAASRole
	at
org.eclipse.jetty.plus.jaas.JAASLoginService.getGroups(JAASLoginService.java:332)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.plus.jaas.JAASLoginService.login(JAASLoginService.java:244)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:47)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.security.authentication.BasicAuthenticator.validateRequest(BasicAuthenticator.java:90)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:492)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1088)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.Server.handle(Server.java:370)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	at java.lang.Thread.run(Thread.java:745)[:1.7.0_80]
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jetty.plus.jaas.JAASRole
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)[:1.7.0_80]
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)[:1.7.0_80]
	at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_80]
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)[:1.7.0_80]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)[:1.7.0_80]
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)[:1.7.0_80]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)[:1.7.0_80]
	at
org.eclipse.jetty.plus.jaas.JAASLoginService.getGroups(JAASLoginService.java:320)[79:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411]
	... 21 more



-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040972.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Security in Module

Posted by Christian Schneider <ch...@die-schneider.net>.
Can you give the full stack trace so we see where the error occurs?

Christian

On 17.06.2015 13:35, kuvalda wrote:
> I've tried to enable basic http auth in etc\jetty.xml and after logging in I
> get an error in karaf.log:
>
> *java.lang.ClassNotFoundException: org.eclipse.jetty.plus.jaas.JAASRole.*
>
> But I found this class in pax web Jetty bundle by karaf console.
>
> Any ideas, what's the problem?
>
>
>
> cschneider wrote
>> A JAAS login is not enough. You also need to call subject.doAs(handler);
>> Inside this call the AccessControlContext will then contain your subject.
>>
>> For web there should be a better way to establish a JAAS context. Maybe
>> you can make pax web or jetty check the authentication and
>> already establish a JAAS context for you. I forwarded to Achim. He might
>> know if that works.
>>
>> Christian
>
>
>
>
> -----
> Pavel
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040970.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>.
I've tried to enable basic http auth in etc\jetty.xml and after logging in I
get an error in karaf.log:

*java.lang.ClassNotFoundException: org.eclipse.jetty.plus.jaas.JAASRole.*

But I found this class in pax web Jetty bundle by karaf console.

Any ideas, what's the problem?



cschneider wrote
> A JAAS login is not enough. You also need to call subject.doAs(handler);
> Inside this call the AccessControlContext will then contain your subject.
> 
> For web there should be a better way to establish a JAAS context. Maybe 
> you can make pax web or jetty check the authentication and
> already establish a JAAS context for you. I forwarded to Achim. He might 
> know if that works.
> 
> Christian





-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040970.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Security in Module

Posted by Christian Schneider <ch...@die-schneider.net>.
A JAAS login is not enough. You also need to call subject.doAs(handler);
Inside this call the AccessControlContext will then contain your subject.

For web there should be a better way to establish a JAAS context. Maybe 
you can make pax web or jetty check the authentication and
already establish a JAAS context for you. I forwarded to Achim. He might 
know if that works.

Christian

On 18.05.2015 17:37, kuvalda wrote:
> One thing to clarify the problem:
> I'm trying to use authentication and authorization in whiteboard servlet.
> There is such a code in doGet for debug:
>
> LoginContext lc = new LoginContext("umrp-realm", callbackHandler);
> lc.login();
> System.out.println(lc.getSubject().getPrincipals());
> Subject subject = Subject.getSubject(AccessController.getContext());
> System.out.println(subject == null);
>
> I have a subject in loginContext after login, but subject in
> AccessControlContext is null.
> So calling the secured methods fails with
> /java.security.AccessControlException No JAAS login present/.
> Am I doing something wrong?
>
>
> kuvalda wrote
>> Hi, Christian!
>> I have questions about getting the authentication result in a place
>> different of where we do authentication.
>> There is such description of Subject.getSubject method In Javadoc:
> *
>> Get the Subject associated with the provided AccessControlContext.
>> The AccessControlContext may contain many Subjects (from nested doAs
>> calls). In this situation, the most recent Subject associated with the
>> AccessControlContext is returned.
> *
>> So we can get that:
>> 1. there is no any Subject in AccessControlContext, if we don't call any
>> secured method. It means, that  just after a simple LoginContext.login()
>> we can't get a Subject from AccessControlContext.
>> 2. If other Subject calls some secured method in the same thread, it
>> replaces the current Subject in AccessControlContext, and the result of
>> Subject.getSubject() will be different.
>>
>> Thanks!
>> 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.
>
>
>
>
> -----
> Pavel
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040447.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>.
One thing to clarify the problem:
I'm trying to use authentication and authorization in whiteboard servlet.
There is such a code in doGet for debug:

LoginContext lc = new LoginContext("umrp-realm", callbackHandler);
lc.login();
System.out.println(lc.getSubject().getPrincipals());
Subject subject = Subject.getSubject(AccessController.getContext());
System.out.println(subject == null);

I have a subject in loginContext after login, but subject in
AccessControlContext is null.
So calling the secured methods fails with
/java.security.AccessControlException No JAAS login present/.
Am I doing something wrong?


kuvalda wrote
> Hi, Christian!
> I have questions about getting the authentication result in a place
> different of where we do authentication.
> There is such description of Subject.getSubject method In Javadoc:
*
> Get the Subject associated with the provided AccessControlContext. 
> The AccessControlContext may contain many Subjects (from nested doAs
> calls). In this situation, the most recent Subject associated with the
> AccessControlContext is returned.
*
> 
> So we can get that:
> 1. there is no any Subject in AccessControlContext, if we don't call any
> secured method. It means, that  just after a simple LoginContext.login()
> we can't get a Subject from AccessControlContext.
> 2. If other Subject calls some secured method in the same thread, it
> replaces the current Subject in AccessControlContext, and the result of
> Subject.getSubject() will be different.
> 
> Thanks!
> 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.





-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040447.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Security in Module

Posted by kuvalda <pe...@mail.ru>.
Hi, Christian!
I have questions about getting the authentication result in a place
different of where we do authentication.
There is such description of Subject.getSubject method In Javadoc:

*Get the Subject associated with the provided AccessControlContext. 
The AccessControlContext may contain many Subjects (from nested doAs calls).
In this situation, the most recent Subject associated with the
AccessControlContext is returned.*

So we can get that:
1. there is no any Subject in AccessControlContext, if we don't call any
secured method. It means, that  just after a simple LoginContext.login() we
can't get a Subject from AccessControlContext.
2. If other Subject calls some secured method in the same thread, it
replaces the current Subject in AccessControlContext, and the result of
Subject.getSubject() will be different.

Thanks!
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.





-----
Pavel
--
View this message in context: http://karaf.922171.n3.nabble.com/Security-in-Module-tp4039307p4040437.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


Re: Security in Module

Posted by kuvalda <pe...@mail.ru>.
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 Andrew Phillips <an...@gmail.com>.
Thanks, that is great information!   

As far as the CXF feature, I actually wrote my own to use in Jersey to do basic authentication (since i am using Jersey and couldn’t find anything out of the box).  I should have a look at the JAASAuthenticationFeature in CXF since it is a RS compliant feature i am guessing to see how it compares.    

Thanks again for all the help!

Andy P


> On Mar 26, 2015, at 2:49 PM, Christian Schneider <ch...@die-schneider.net> 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 <https://fisheye6.atlassian.com/browse/~br=trunk/aries/trunk/blueprint/blueprint-authz>
> And an example: 
> https://github.com/cschneider/Karaf-Tutorial/tree/master/cxf/personservice/server <https://github.com/cschneider/Karaf-Tutorial/tree/master/cxf/personservice/server>
> https://github.com/cschneider/Karaf-Tutorial/blob/master/cxf/personservice/server/src/main/resources/OSGI-INF/blueprint/blueprint.xml <https://github.com/cschneider/Karaf-Tutorial/blob/master/cxf/personservice/server/src/main/resources/OSGI-INF/blueprint/blueprint.xml>
> https://github.com/cschneider/Karaf-Tutorial/blob/master/cxf/personservice/server/src/main/java/net/lr/tutorial/karaf/cxf/personservice/impl/PersonServiceImpl.java <https://github.com/cschneider/Karaf-Tutorial/blob/master/cxf/personservice/server/src/main/java/net/lr/tutorial/karaf/cxf/personservice/impl/PersonServiceImpl.java>
> 
> The example uses cxf and the cxf JAASAuthenticationFeature for establishing the JAAS login and the blueprint authz module to do the authorization using @RolesAllowed.
> So while the example uses cxf you the authorization part is in no way tied to cxf. You can use it together with your own login code.
> 
> Christian
> 
> 
> On 26.03.2015 20:33, Andrew Phillips wrote:
>> Now that i do it, seems so simple.  The trick is that the Principals are exposed as Group and Role principals from the karaf boot module.   
>> 
>> Maybe an example of how to do something like that would be helpful on the site.    I’d be more than happy to give an example or update it myself somewhere:
>> 
>> Subject subject = new Subject();
>> LoginContext loginContext = new LoginContext(karafRealm, subject, new CallbackHandler() {
>>     @Override
>>     public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
>>         for (Callback callback : callbacks) {
>>             if (callback instanceof NameCallback) {
>>                 ((NameCallback) callback).setName(userName);
>>             }
>>             if (callback instanceof PasswordCallback) {
>>                 ((PasswordCallback) callback).setPassword(password).toCharArray());
>>             }
>>         }
>>     }
>> });
>> loginContext.login();
>> then you can say something like:
>> 
>> public boolean isUserInGroup(String g) {
>>     for (GroupPrincipal principal : subject.getPrincipals(GroupPrincipal.class)) {
>>         if (principal.getName().equals(g)) return true;
>>     }
>>     return false;
>> }
>> 
>> public boolean isUserInRole(String s) {
>>     for (RolePrincipal principal : subject.getPrincipals(RolePrincipal.class)) {
>>         if (principal.getName().equals(s)) return true;
>>     }
>>     return false;
>> }
>> Great product, Karaf!   Love it, thanks!
>> Andy P
>> 
>> 
>> 
>> 
>>> On Mar 26, 2015, at 1:37 AM, Jean-Baptiste Onofré <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>> 
>>> Hi Andy,
>>> 
>>> you can directly use the JAAS subject provider.
>>> 
>>> You get a LoginContext and Subject.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 03/26/2015 01:47 AM, Andrew Phillips wrote:
>>>> I am hoping to utilize the Karaf security module in a bundle of mine.   What is the best way, if there is an example, of authenticating a user if i have a user name and password and getting back the roles so i can use the built in security module?
>>>> 
>>>> I appreciate the help.   Love the product, I am using Karaf 3.0.3.
>>>> 
>>>> 
>>>> Thanks!
>>>> Andy P
>>>> 
>>>> 
>>> 
>>> -- 
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <ma...@apache.org>
>>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>>> Talend - http://www.talend.com <http://www.talend.com/>
>> 
> 
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
> 
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>


Re: Security in Module

Posted by Christian Schneider <ch...@die-schneider.net>.
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
And an example:
https://github.com/cschneider/Karaf-Tutorial/tree/master/cxf/personservice/server
https://github.com/cschneider/Karaf-Tutorial/blob/master/cxf/personservice/server/src/main/resources/OSGI-INF/blueprint/blueprint.xml
https://github.com/cschneider/Karaf-Tutorial/blob/master/cxf/personservice/server/src/main/java/net/lr/tutorial/karaf/cxf/personservice/impl/PersonServiceImpl.java

The example uses cxf and the cxf JAASAuthenticationFeature for 
establishing the JAAS login and the blueprint authz module to do the 
authorization using @RolesAllowed.
So while the example uses cxf you the authorization part is in no way 
tied to cxf. You can use it together with your own login code.

Christian


On 26.03.2015 20:33, Andrew Phillips wrote:
> Now that i do it, seems so simple.  The trick is that the Principals 
> are exposed as Group and Role principals from the karaf boot module.
>
> Maybe an example of how to do something like that would be helpful on 
> the site.    I’d be more than happy to give an example or update it 
> myself somewhere:
>
> Subject subject =newSubject();
> LoginContext loginContext =newLoginContext(karafRealm, subject,newCallbackHandler() {
>      @Override
>      public voidhandle(Callback[] callbacks)throwsIOException, UnsupportedCallbackException {
>          for(Callback callback : callbacks) {
>              if(callbackinstanceofNameCallback) {
>                  ((NameCallback) callback).setName(userName);
>              }
>              if(callbackinstanceofPasswordCallback) {
>                  ((PasswordCallback) callback).setPassword(password).toCharArray());
>              }
>          }
>      }
> });
> loginContext.login();
> then you can say something like:
>
> public booleanisUserInGroup(String g) {
>      for(GroupPrincipal principal :subject.getPrincipals(GroupPrincipal.class)) {
>          if(principal.getName().equals(g))return true;
>      }
>      return false;
> }
>
> public booleanisUserInRole(String s) {
>      for(RolePrincipal principal :subject.getPrincipals(RolePrincipal.class)) {
>          if(principal.getName().equals(s))return true;
>      }
>      return false;
> }
> Great product, Karaf!   Love it, thanks!
> Andy P
>
>
>
>
>> On Mar 26, 2015, at 1:37 AM, Jean-Baptiste Onofré <jb@nanthrax.net 
>> <ma...@nanthrax.net>> wrote:
>>
>> Hi Andy,
>>
>> you can directly use the JAAS subject provider.
>>
>> You get a LoginContext and Subject.
>>
>> Regards
>> JB
>>
>> On 03/26/2015 01:47 AM, Andrew Phillips wrote:
>>> I am hoping to utilize the Karaf security module in a bundle of 
>>> mine.   What is the best way, if there is an example, of 
>>> authenticating a user if i have a user name and password and getting 
>>> back the roles so i can use the built in security module?
>>>
>>> I appreciate the help.   Love the product, I am using Karaf 3.0.3.
>>>
>>>
>>> Thanks!
>>> Andy P
>>>
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Re: Security in Module

Posted by Andrew Phillips <an...@gmail.com>.
Now that i do it, seems so simple.  The trick is that the Principals are exposed as Group and Role principals from the karaf boot module.   

Maybe an example of how to do something like that would be helpful on the site.    I’d be more than happy to give an example or update it myself somewhere:

Subject subject = new Subject();
LoginContext loginContext = new LoginContext(karafRealm, subject, new CallbackHandler() {
    @Override
    public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
        for (Callback callback : callbacks) {
            if (callback instanceof NameCallback) {
                ((NameCallback) callback).setName(userName);
            }
            if (callback instanceof PasswordCallback) {
                ((PasswordCallback) callback).setPassword(password).toCharArray());
            }
        }
    }
});
loginContext.login();
then you can say something like:

public boolean isUserInGroup(String g) {
    for (GroupPrincipal principal : subject.getPrincipals(GroupPrincipal.class)) {
        if (principal.getName().equals(g)) return true;
    }
    return false;
}

public boolean isUserInRole(String s) {
    for (RolePrincipal principal : subject.getPrincipals(RolePrincipal.class)) {
        if (principal.getName().equals(s)) return true;
    }
    return false;
}
Great product, Karaf!   Love it, thanks!
Andy P




> On Mar 26, 2015, at 1:37 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 
> Hi Andy,
> 
> you can directly use the JAAS subject provider.
> 
> You get a LoginContext and Subject.
> 
> Regards
> JB
> 
> On 03/26/2015 01:47 AM, Andrew Phillips wrote:
>> I am hoping to utilize the Karaf security module in a bundle of mine.   What is the best way, if there is an example, of authenticating a user if i have a user name and password and getting back the roles so i can use the built in security module?
>> 
>> I appreciate the help.   Love the product, I am using Karaf 3.0.3.
>> 
>> 
>> Thanks!
>> Andy P
>> 
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com


Re: Security in Module

Posted by Cristiano Costantini <cr...@gmail.com>.
Hi Andy,
some time ago I did some test to use Spring Security within Karaf,
the code I wrote for this study is published here:
https://github.com/cristcost/springsec

It is a very specific use case, in particular it is not a bundle but it is
a War that is osgi-fied, but there is implemented a spring security login
form so you may find it interesting.
If you find it useful and have questions about it, feel free to ask.

Regards,
Cristiano





Il giorno gio 26 mar 2015 alle ore 07:39 Jean-Baptiste Onofré <
jb@nanthrax.net> ha scritto:

> Hi Andy,
>
> you can directly use the JAAS subject provider.
>
> You get a LoginContext and Subject.
>
> Regards
> JB
>
> On 03/26/2015 01:47 AM, Andrew Phillips wrote:
> > I am hoping to utilize the Karaf security module in a bundle of mine.
>  What is the best way, if there is an example, of authenticating a user if
> i have a user name and password and getting back the roles so i can use the
> built in security module?
> >
> > I appreciate the help.   Love the product, I am using Karaf 3.0.3.
> >
> >
> > Thanks!
> > Andy P
> >
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Security in Module

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Andy,

you can directly use the JAAS subject provider.

You get a LoginContext and Subject.

Regards
JB

On 03/26/2015 01:47 AM, Andrew Phillips wrote:
> I am hoping to utilize the Karaf security module in a bundle of mine.   What is the best way, if there is an example, of authenticating a user if i have a user name and password and getting back the roles so i can use the built in security module?
>
> I appreciate the help.   Love the product, I am using Karaf 3.0.3.
>
>
> Thanks!
> Andy P
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com