Provide an OSGi friendly security framework

[BryanHunt]

I've been looking for documentation on how to do security in Jersey that would apply to an OSGi environment. The best I've found so far is:

http://porterhead.blogspot.fr/2013/01/writing-rest-services-in-java-part-6.html

I'm thinking a security framework that used a whiteboard pattern to plug in an authorizer and an enroller would be a good addition. If this sounds useful, I will start to work on a solution.

[BryanHunt]

I have an implementation that introduces two OSGi services that clients must implement:

public interface AuthenticationService
{
  Principal authenticate(ContainerRequestContext requestContext);
}

and

public interface AuthorizationService
{
  boolean isUserInRole(Principal user, String role);
}

I would propose placing the API into the bundle: com.eclipsesource.jaxrs.security

I would propose placing the providers that consume the above API into the bundle: com.eclipsesource.jaxrs.provider.security

Does this packaging seem ok?

[hstaudacher]

Hi Bryan, I don't get it :)

I mean how does this work? The providers will consume the 2 services and call the methods, right? How does this comply with jax-rs annotations like '@RolesAllowed'? I just can't get the whole flow into my mind. Can you tell me a little bit more about how this works?

Why would you split up this into 2 security bundles? I mean, can they work without each other? When the providers consume the 2 services the provider bundle would be required. If this is the case why not putting the providers into an internal package and only have one security bundle?

[BryanHunt]

The two service interfaces are a whiteboard pattern with only one expected implementation by the user. My code does not provide implementations of those services. You could argue that the two services should be combined into a single service. I separated the two services based on my experience with Restlet. They have a separation between authentication and authorization. The provider code uses the services and registers the optional roles features such that @RolesAllowed works. If you want to see the code in its current state, have a look at my fork: https://github.com/BryanHunt/osgi-jax-rs-connector

[hstaudacher]

Alright, now I got it, thanks! The following came into my mind:

• Separation of authentication and authorization is good.
• I still think this should all go in one bundle, e.g. com.eclipsesource.jaxrs.security. This is because a user of this does have to implement the 2 services but he also needs to know that he needs to include the provider. If not nothing would happen. From my point of view this will be a point of failure for sure. My suggestion is to put the provider into the security bundle but into an internal package. The only exported package will be the "api" package containing the interfaces the user needs to implement. If so a user would need to import the api package and this would make him aware that he also needs to add the security bundle in his osgi instance. -> Point of failure eliminated ;)
• Before this can go into the main repository we need to change it to not us Declarative Services. I think as a library we can't force the use of DS. We should use bare ServicesTrackers here. I know it's not that cool but we need to make sure developer not using DS also will be able to use the connector.
• An example how this works in action would be cool ;)
• I don't see any tests ;)

I think if this is done it will be a very cool feature, thanks for the work you putting into this.

[BryanHunt]

I separated the API from the implementation in case someone wanted to provide an alternate implementation. This is the same design pattern used by OSGi. If this doesn't convince you, I will shove everything into a single bundle.

IMHO, having a dependency on declarative services easily outweighs the complexity of using ServiceTracker. All of my open source projects require it, and I've never had a user complain. If you really want to be independent of DS, I'll change the code but still strongly object.

Examples and tests will be added once the packaging is sorted out.

[hstaudacher]

Ok, if you think there could be another implementation then I'm fine with it. ;)

Yes I want the connector to be independent of DS. This has two reasons:

1. Everything so far implemented in the connector does not require ds. I don't think we should change this to not confuse people. I mean we are using the connector as some kind of a core library now. Every server project we are doing uses this project. I think keeping the dependencies at a minimum is a good thing.
2. We are using the connector in some projects were ds is not used (don't ask ;)). So, I don't wan't to force them to use ds if they want to use the security feature.

[BryanHunt]

I have removed the dependencies on DS and those changes have been pushed to my fork if you want to have a look. I've started writing the tests and I hope to have those done this weekend.

[BryanHunt]

I have pushed a working example to my fork. The unit test is proving to be a bit of a challenge. I think I'm going to have to make it an integration test running inside an OSGi container.

[hstaudacher]

starting review today

[hstaudacher]

I will close this issue because the discussion is now on issue #20