Environment:
oauth2.client.* with * equal to clientId, clientSecret,
-tokenUri and authorizationUri and;
tokenUri, authorizationUri and one of:
oauth2.resource.preferTokenInfo=false and
@@ -2357,6 +2357,64 @@ provide a URI where it can be downloaded (as a JSON object with a
{"alg":"SHA256withRSA","value":"-----BEGIN PUBLIC KEY-----\nMIIBI...\n-----END PUBLIC KEY-----\n"}
+
You can set the preferred scope (as a comma-separated list or YAML
+array) in oauth2.client.scope. It defaults to empty, in which case
+most Authorization Servers will ask the user for approval for the
+maximum allowed scope for the client.
There is also a setting for oauth2.client.authenticationScheme which
+defaults to "header" (but you might need to set it to "form" if, like
+Github for instance, your OAuth2 provider doesn’t like header
+authentication).
By default the whole application will be secured with OAuth2 with the
+same access rule ("authenticated"). This includes the Actuator
+endpoints, which you might prefer to be secured differently, so Spring
+Cloud Security provides a configurer callback that lets you change the
+matching and access rules for OAuth2 authentication. Any bean of type
+OAuth2SsoConfigurer (there is a convenient empty base class) will
+get 2 callbacks, one to set the request matchers for the OAuth2
+filter, and one with the full HttpSecurity builder (so you can set
+up all sorts of behaviour, but the main application is to control
+access rules).
The default login path, i.e. the one that triggers the redirect to the
+OAuth2 Authorization Server, is "/login". It will always be added to
+the matching patterns for the OAuth2 SSO, even if you have
+OAuth2SsoConfigurer beans as well. The default logout path is
+"/logout" and it gets similar treatment, as does the "home" page
+(which is the logout success page, defaults to "/"). Those paths can
+be overriden by setting oauth2.sso.\*' (`loginPath, logoutPath and
+home.path).
For example if you want the resources under "/ui/**" to be protected with OAuth2:
+@Configuration
+@EnableOAuth2Sso
+@EnableAutoConfiguration
+protected static class TestConfiguration extends OAuth2SsoConfigurerAdapter {
+ @Override
+ public void match(RequestMatchers matchers) {
+ matchers.antMatchers("/ui/**");
+ }
+}In this case the rest of the application will default to the normal +Spring Boot access control (Basic authentication, or whatever custom +filters you put in place).
+oauth2.*. Spring Cloud
for Cloud Foundry just sets up default environment properties so that
it all just works if you bind to a Cloud Foundry service instance
called "sso". The service credentials are mapped to the SSO
-properties, i.e. clientId, clientSecret, tokenUri,
-authorizationUri, userInfoUri, tokenInfoUri1, `jwt.\* (refer to
-the Spring Cloud Security documentation for details of which
-combinations will work together). The main thing is that in Cloud
-Foundry you only need one service to cover all the necessary
-credentials.
+properties, i.e. (from oauth2.client.*) clientId, clientSecret,
+tokenUri, authorizationUri, (and from oauth2.resource.*)
+userInfoUri, tokenInfoUri, keyValue, keyUri. Refer to the
+Spring Cloud Security documentation for details of which combinations
+will work together. The main thing is that in Cloud Foundry you only
+need one service to cover all the necessary credentials.
To use a different sercice instance name (i.e. not "sso") just set @@ -2528,10 +2586,10 @@ credentials.
Spring Cloud Security already has support for decoding JWT tokens if
you just provide the verification key (as an environment property). In
Cloud Foundry you can pick that property up from a servcice binding
-(jwt.keyValue or jwt.keyUri).
keyValue or keyUri).
For example the jwt.keyUri in PWS is
+
For example the keyUri in PWS is
"https://uaa.run.pivotal.io/token_key":
$ cf create-user-provided-service resource -p '{jwt.keyUri:"https://uaa.run.pivotal.io/token_key"}
+$ cf create-user-provided-service resource -p '{keyUri:"https://uaa.run.pivotal.io/token_key"}
To use JWT you need to add the verification key as either
-jwt.keyValue or jwt.keyUri (these could be added to the "sso"
+keyValue or keyUri (these could be added to the "sso"
service or the "resource" service if you have one).
The precise mapppings are as follows:
oauth2.client.* to vcap.services.${oauth2.sso.serviceId:sso}.credentials.tokenUri:${vcap.services.${oauth2.resource.serviceId:resource}.credentials.*
oauth2.resource.* to vcap.services.${oauth2.resource.serviceId:resource}.credentials.tokenUri:${vcap.services.${oauth2.sso.serviceId:sso}.credentials.*
oauth2.resource.(jwt).* to vcap.services.${oauth2.resource.serviceId:resource}.credentials.tokenUri:${vcap.services.${oauth2.sso.serviceId:sso}.credentials.*