Security problems and considerations

[BryanHunt]

The way the security filter is implemented, all requests must go through the filter which causes certain use cases to fail. I am currently experimenting with Basic and Form based authentication and I have run into problems.

To get Basic authentication working, you must throw a NotAuthorizedException("Basic") from the security handler's authenticate() function for Jersey to properly return a 401 to the browser with the proper WWW-Authenticate: Basic response header. This means that you can't return null if authentication fails. This also means that you can't have un-authenticated routes since the filter sees all requests.

To get Form authentication working, you must have some sort of un-authenticated session route that creates the cookie / token to be used for authorization. In this case, you can get around the filter by returning null for the principal during authentication to the session route. The secure routes can then rely on the authorization() hook to verify the session cookie / token. This has the potential to be problematic for certain clients since the user will get a 403 if they do not have a session token instead of the desired 401.

We could consider creating a configuration for the security filter to specify which routes are secure and which are public. Another option (which I currently like better) would be to support multiple root URLs where each root can have it's own security filter (or not). So instead of all services being registered under /services, you might have some registered under /services/public and some under /services/secure. This implementation has the added benefit of allowing multiple "applications" to be served in the same container.

[hstaudacher]

Ok. So it's a problem with the security integration and not a vulnerability, right?

[BryanHunt]

Correct.

[hstaudacher]

Hmm as far as I know multi httpservice support it's already implemented. Seems we have missed to couple the security integration well.

[hstaudacher]

Currently we hold one instance of the AuthenticationHandler and AuthorizationHandler in the providers Activator.

We need to make it a 0..n relationship first. The second topic is to couple the handlers to a specific path. I see no difference in your two suggestions. For both ways we need to bind the handlers to a path in some way. Either with programatic API or by a service property. So, enhancing the connector to allow registration of different resources on different pathes using one HttpService is a different story I think.

Any thoughts?

[thanhlq]

I faced with this situation also. I workaround by checking the route if starting with /services/public/... then I consider as authenticated (return a dummy principle)... Obviously we need a clean way!

I could imagine a final using scenarios is as following: We register a service as usual but with a special annotation as @PublicPath then that service shall be registered under a truly public path as /public-services/v1/authenticate

@Path("/v1/authenticate")
@PublicPath
public interface IWebAuthenticationService {
}