[mitreid-connect] protecting authorize endpoint

[Zhanna Tsitkov]

The reason why you are prompted to log in is the following exception thrown  in AuthorizationEndpoint:authorize

if (!(principal instanceof Authentication) || !((Authentication) principal).isAuthenticated()) {
throw new InsufficientAuthenticationException(
"User must be authenticated with Spring Security before authorization can be completed.");
}


If a user is not authenticated at all, then principal equals to null and exception is generated.  Then this exception in intercepted by ExceptionTranslator and the user is forced to log in. However, if principal is already somehow authenticated this check passes.  This check does not require for user to be authenticated with authority ROLE_USER.

I suggest to debug this code to better understand the issue.

Thanks,
Zhanna

On Aug 21, 2015, at 9:43 AM, Justin Richer <jricher at MIT.EDU<mailto:jricher at MIT.EDU>> wrote:

I am unable to replicate the exploit. Even when the client has been whitelisted, when going to the authorization endpoint, I am prompted to log in. I am unable to generate a token from an unauthenticated user, and so I don’t believe this is a security issue.

 — Justin

On Aug 21, 2015, at 9:30 AM, Zhanna Tsitkov <tsitkova at mit.edu<mailto:tsitkova at mit.edu>> wrote:

Justin,
While debugging workflow related to authorization code request I found that authorization  EP provided by Spring Security OAuth2 (org.springframework.security.oauth2.provider.endpoint.AuthorizationEndpoint)  namespace is not protected as it’s supposed. I was able to enter this EP without any authentication.  Section "Configuring the Endpoint URL“ of “OAuth 2 Developer Guide” states  (See https://github.com/spring-projects/spring-security-oauth/blob/master/docs/oauth2.md): “N.B.  The Authorization endpoint /oauth/authorize (or its mapped alternative) should be protected using Spring Security so that it is only accessible to authenticated users.“.  The example provided in the document implies that the endpoint must be protected from outside by the Spring Security framework.
There is some sort of protection within the endpoint itself, but it certainly does not require ROLE_USER  authority as you suggested previously. I was able to pass internal security check using different role.
On the other hand, the other OAuth2 endpoint responsible for user approval process  "/oauth/confirm_access” is protected as  expected.
Thus, this endpoint mitigate the lack of proper security for authorize endpoint. But, it seems to me that for white-listed clients  it does not matter.

In my opinion it is a security issue of MitreID Connect.

Thanks,
Zhanna

On Aug 20, 2015, at 4:48 PM, Justin Richer <jricher at MIT.EDU<mailto:jricher at MIT.EDU>> wrote:

I suggest reading the documentation for Spring Security and Spring Security OAuth.

 — Justin

On Aug 20, 2015, at 10:21 AM, Zhanna Tsitkov <tsitkova at mit.edu<mailto:tsitkova at mit.edu>> wrote:

ok. Sounds good. Can you please point to a particular place where this is implemented.

Thanks,
Zhanna

On Aug 20, 2015, at 10:14 AM, Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>> wrote:

The rest of Spring Security, which is configured throughout the code, outside the XML. Specifically, the authorization endpoint requires ROLE_USER to access.

 — Justin

On Aug 20, 2015, at 10:04 AM, Zhanna Tsitkov <tsitkova at mit.edu<mailto:tsitkova at mit.edu>> wrote:

In this block access intercept is set to permitAll: <security:intercept-url pattern="/**" access="permitAll" />
What mechanism is used to protect this EP?

Thanks,
Zhanna

On Aug 20, 2015, at 9:47 AM, Justin Richer <jricher at MIT.EDU<mailto:jricher at MIT.EDU>> wrote:

As it says in the paragraph of documentation that you quoted below, it’s protected the same way that the rest of the UI is protected. This is handled in the main <security:http> block in user-context.xml.

 — Justin

On Aug 20, 2015, at 9:45 AM, Zhanna Tsitkov <tsitkova at mit.edu<mailto:tsitkova at mit.edu>> wrote:

Hi,
According to the documentation for configure method of  AuthorizationServerConfigurer interface
"



        * The /oauth/authorize endpoint also needs to be secure, but that is a normal user-facing endpoint and should be
        * secured the same way as the rest of your UI, so is not covered here. The default settings cover the most common
        * requirements, following recommendations from the OAuth2 spec, so you don't need to do anything here to get a
        * basic server up and running.
"
In MitreID Connect it looks like  this EP is not explicitly protected.   How it is done?
Thanks,
Zhanna
_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
http://mailman.mit.edu/mailman/listinfo/mitreid-connect








-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150821/ef0732f0/attachment-0001.html