pre-established-redirect-uri in oauth:resource

[wolter]

Hi,

I'm trying to get a <oauth:resource ..> working with a pre-established-redirect-uri, but there seems to be something missing.

We have a setup that looks like the /foo and /bar as described in SECOAUTH-96 (https://jira.springsource.org/browse/SECOAUTH-96)

If I not configure a pre-established-redirect-uri and the resource-owner grants access we get redirected back to the correct uri.
I want to configure a pre-established-redirect-uri but I am not sure where to point that to, and which controller or filter to configure to consume the code and redirect to the uri that triggered authorization.

In other words what is implementing: "client enters /callback endpoint and forwards to /foo" as described in SECOAUTH-96.

The only place I can find the redirect uri is read back from the state is in
OAuth2RestTemplate.acquireAccessToken(OAuth2Client Context oauth2Context)
the state (containing the currentUri) get copied back to the accessTokenRequest.
The currentUri in the state only seems to be used to detect CSRF.

I'm using spring-security-oauth2-1.0.0.M6d

Regards,
Wolter

[Dave Syer]

If I not configure a pre-established-redirect-uri and the resource-owner grants access we get redirected back to the correct uri.
I want to configure a pre-established-redirect-uri but I am not sure where to point that to, and which controller or filter to configure to consume the code and redirect to the uri that triggered authorization.

It shouldn't be any different with a pre-registered value - whatever the redirect you send to the server, you have to be able to handle it, so you have to provide a controller or other handler, and it has to go through the ClientContextFilter (the one created with <oauth:client/>). Does that make sense?

[wolter]

So I need to create a special controller for let say /.../pre-established-callback that does the following
1. restTemplate.getAccessToken();
2. uri = (String) restTemplate.getOAuth2ClientContext().getPreserved State();
3. RedirectStrategy.sendRedirect(...., uri)

Can't the OAuth2ClientContextFilter detect a request to a pre-established-redirect-uri? consume the code and redirect the the uri saved in the preservedState?

Regards,
Wolter

[Dave Syer]

Can't the OAuth2ClientContextFilter detect a request to a pre-established-redirect-uri? consume the code and redirect the the uri saved in the preservedState?

I'm not sure what you mean. That *is* what the OAuth2ClientContextFilter does isn't it? (Except that if the pre established uri is used the preserved state is not used.) You might need to add use-current-uri="false" to the resource declaration to make sure the registered value is always used.

[wolter]

Maybe I need to ask my question in a different way.

If a authorization server requires you to configure a pre-established-redirect-uri how do I end up at my the Controller that triggered the authorization request?

I'd like to configure the pre-established-redirect-uri so all redirects for a resource go to one place.
And then redirect to the uri/controller that triggered the authorization request.
In this way the code and state attribute will not remain in the url bar on the browser, and in the referrer header.
I'm also a bit worried now about page reloads with the code and state attribute still in the page url.

[Dave Syer]

If a authorization server requires you to configure a pre-established-redirect-uri how do I end up at my the Controller that triggered the authorization request?

An Authorization Server should *always* require a client to register a redirect URI for implicit or auth code grants. But, just for the sake of clarity, that doesn't mean you have to use the pre-registered* and use-current-uri features in your client.

I'd like to configure the pre-established-redirect-uri so all redirects for a resource go to one place.
And then redirect to the uri/controller that triggered the authorization request.
In this way the code and state attribute will not remain in the url bar on the browser, and in the referrer header.
I'm also a bit worried now about page reloads with the code and state attribute still in the page url.

I assume from this that actually you would prefer to use the client-side features to do with a pre-registered URI. Obviously if all your authorization requests redirect to the same URI you will have to write the handler for that URI quite carefully, so that it can somehow extract some state from the request and redirect to the final endpoint. IMO it's not worth the hassle (the code and state parameters are not usable by bad guys by the time the request has finished processing), but it's entirely up to you how you want to do that. You could, for example, use a query parameter in your pre-registered-* client declaration which the controller could pull out and use to determine the next location for a redirect. To hide the code and state parameters in the browser it would have to be a redirect, not a forward, and hence any state that was needed in the final handler needs to be stored in between requests (e.g. in the HttpSession).

Of course, if you have to store state anyway, you might as well use that to store the redirect location in the first step, so using a query parameter is not the only way to find out where to go next in the global redirect handler.

[wolter]

Hi Dave,

I've had a 10 hours flight to look over everything to look over the configuration again, and I see what you mean.
I have cleared the use-current-uri and pre-established-redirect-uri from the resource elements and configured the uri in the authentication server only.

Now I've got that part working, I've run in to another thing.

I've tried to configure a password encoder for my clients but discovered there are two implementations:

org.springframework.security.authentication.encodi ng.PasswordEncoder
and
org.springframework.security.crypto.password.Passw ordEncoder

I've configured the following:

	<authentication-manager id="client-authentication-manager" xmlns="http://www.springframework.org/schema/security">
		<authentication-provider user-service-ref="client-details-user-service">
			<password-encoder ref="passwordEncoder">
				<salt-source user-property="username" />
			</password-encoder>
		</authentication-provider>
	</authentication-manager>

	<bean id="client-details" class="org.springframework.security.oauth2.provider.JdbcClientDetailsService">
		<constructor-arg ref="dataSource" />
                <property name="passwordEncoder" ref="passwordEncoder"/>
	</bean>

But found the interfaces/implementations of the passwordEncoders to be different.

Regards,
Wolter

[Dave Syer]

It should be clear from the JdbcClientDetailsService that it is looking for the crypto version (it's a newer interface).

[wolter]

That was clear to me, but it was not clear I could also use that one for the authentication-provider.

[Dave Syer]

From the Spring Security user guide (http://static.springsource.org/sprin...ord-encoding):

"Spring Security's PasswordEncoder interface is used to support the use of passwords which are encoded in some way in persistent storage. This will normally mean that the passwords are “hashed” using a digest algorithm such as MD5 or SHA. Spring Security 3.1's crypto package introduces a simpler API which encourages best-practice for password hashing. We would encourage you to use these APIs for new development and regard the classes in package org.springframework.security.authentication.encodi ng as legacy implementations. The DaoAuthenticationProvider can be injected with either the new or legacy PasswordEncoder types."