As we continue from the last release, some of the challenges other than Azure ID and Summit User ID mismatch are discussed below.
Also, learn how you can integrate SSO with GreenPoint’s Summit application.
To review the previous release, please click here.
Unexpected ‘Session Timeout’
Summit, after logging in, would log out the user forcibly.
- OIDC requests access tokens after a specific percentage of token lifespan. The SummitFT.exe.config has an OpenIDRefreshMarginPercentage tag, which is a configurable value after which the OIDC refresh access token will be initiated.
- Summit was not requesting a refresh token from MS Azure and this was causing a forceful logout.
This issue was identified by the team from the Azure side, where it was identified that Summit was not requesting a refresh token during the authentication with Azure AD. The response received included a
‘null ID Token’ value. This token timeout caused the users to forcefully log out of the current Summit session as the token value received was null.
This was handled programmatically, and the token was requested at the end of the refresh margin time percentage set in ‘SummitFT.exe.config’.
The ‘Timeout’ issue was therefore resolved, but there was one more challenge to overcome.
Microsoft changes ‘Keys’ periodically, preventing user access…
Once SSO was established, a security feature was discovered that blocked its use over longer periods of time.
- The Summit backend used to have a hardcoded key which was being used to decrypt the user access token. This hardcoded token was available as a part of sso.xml.
- This key would be changed by Microsoft based on its own schedule, and it would happen on an ad hoc basis.
- If the key is changed by Microsoft Azure, users will not be able to login to Summit, and this will cause downtime for business users.
- This was resolved by the team by programmatically fetching the key values dynamically from Azure, which was used to decrypt the user token.
As a part of the sso.xml, well_Known_Url is provided, which was used to fetch all the available keys in jwks_uri while using the correct key to decrypt the user access token.
Ultimately, SSO was enabled and made robust by recognizing the issues caused by mismatches between Summit and Azure, and knowing how to circumvent these differences through the deep expertise of both Azure and Summit.
Summit SSO Authentication and Authorization workflow
When SSO is used in conjunction with an identity and access management (IAM) system, a central directory is used to regulate user access to resources on a more granular level. This enables businesses to comply with regulations that demand that users be given the necessary permissions.
Summit SSO handles both authentication and authorization with the workflow described below:
Find out about the other challenges encountered by GreenPoint Summit during SSO integration in our next release.
Be sure to check out this space for more interesting summit topics!
