Issuer Validation Regression in Spring Cloud SSO Connector
Article ID: 297115
Updated On:
Products
Issue/Introduction
This article applies to Spring Cloud Services for VMware Tanzu.
You are affected if all the statements below are true:
- You are using Single Sign-On Service on PCF / TAS and created more than one SSO Service Plan on the same PCF / TAS deployment
- You have Spring Boot Applications utilizing the @EnableResourceServer annotation
- You are importing the Spring SSO Connector version 2.1.2 for your resource server applications and are not binding them to the SSO service
The Single Sign-On Service uses a shared private key when signing tokens within a PCF / TAS deployment. The tokens are signed with the same private key and validating the token signature is not sufficient to prove the source of the token across plans.
The Single Sign-On Service provides a sample application for the Resource Server which utilizes Spring Boot and performs offline validation of the token. As part of the offline validation, it checks the signature and expiry of the token. Issuer check was later added by the SSO Connector version 2.1.1, as the issuer is one of the claims on the token and is unique per plan.
For Spring SSO Connector version 2.1.2, a regression occurred where the configurations that enabled the issuer check behavior in the SSO connector were turned off if the resource server application relied on the AUTH_SERVER environment variable to locate the SSO Auth Domain instead of binding to the SSO service.
Resolution
The OAuth standard describes four roles: resource owners (users), clients, resource servers, and authorization servers. In a typical flow, an OAuth client will obtain a token on behalf of a user and then send that token in the Authorization header when making requests to a Resource Server (An API or a Microservice). The security of this model depends on the Resource Server verifying the authenticity, validity, and source of the token before granting access to protected API endpoints.
The tokens issued by the SSO Service are JSON Web Tokens which contain three parts: a header, a body containing claims, and a signature. These tokens may be decoded to find claims that a Resource Server must validate.
Example:
$ uaac token decode jti: be209a40e73e42c5ba11505506256999 sub: f4be8b07-adbb-4924-a209-a91f9b15c203 scope: openid uaa.user cloud_controller.read password.write cloud_controller.write client_id: cf cid: cf azp: cf grant_type: password user_id: f4be8b07-adbb-4924-a209-a91f9b15c203 origin: uaa user_name: [email protected] email: demouser@> auth_time: 1498585425 rev_sig: 3c817c73 iat: 1498585425 exp: 1498586025 iss: https://sso-domain-1.uaa.acme.com/oauth/token zid: uaa aud: cloud_controller password cf uaa openid
Resource servers have the option of calling the /check_token endpoint to validate a token. But, for performance reasons, applications may validate tokens offline by ensuring all of the following:
- Signature Validation (using a public key obtained from the UAA’s by going to the token_keys and then to the endpoint)
- Expiry Check (using the exp claim from the decoded JWT token body)
- Issuer Validation (using the ISS claim from the decoded JWT token body)
Mitigation for the regression in Spring SSO Connector version 2.1.2
The customer can perform any of the following options to mitigate the issue:
- Update the application's version of Spring-Cloud-SSO-Connector to version 2.1.3 and above
- Set “sso.connector.cloud.available=true” within your Spring application properties
- Bind your resource server to the SSO service as a client credentials application. This will also allow the resource server to perform calls against UAA on behalf of itself.
Additional Information
Frequently Asked Questions
What is the impact on Spring Boot application?
The applications should perform dependency changes listed above for Spring Boot, Spring Security, and the SSO connector. Also, they should be able to run on the updated Spring Boot version. This may require additional code changes based on Spring Boot’s required upgrade. Following that, the application should be re-deployed which may involve application downtime.
What is the impact on the SSO service tiles?
With the implementation of the issuer check for your applications, no changes will be required for your existing SSO service tiles and configurations.
Why can't I switch my resource server to switch to check_token instead?
There are performance implications in terms of calling into a central point for validating every API request and this problem becomes worse in a distributed context. We recommend calling into check_token only when performing highly privileged operations whose frequency is low.
What if my resource server is not running on Cloud Foundry / Tanzu Application Service?
If your application runs outside of Cloud Foundry / Tanzu Application Service but is using Spring Boot, include SSO Connector as a dependency to take advantage of the IssuerClaimVerifier logic we have implemented that works with PCF ERT 1.9 and above.
What if my resource server is not running on Spring Boot?
If your application does not use Spring Boot, check if your library supports the issuer check and make sure it is implemented for your resource server. The issuer for your Service Plan can be identified via the OIDC well-known endpoint at https://<your_plan_subdomain>.login.<your_domain.com>/.well-known/openid-configuration to find the UAA’s OIDC metadata. The response should be something like:
{
"issuer": "https://sso-domain-1.uaa.acme.com/oauth/token",
"authorization_endpoint": "https://uaa.acme.com/oauth/authorize",
"token_endpoint": "https://uaa.acme.com/oauth/token",
"token_endpoint_auth_methods_supported": [
"client_secret_basic",
"client_secret_post"
],
< … truncated response >
}
Feedback
