Single Sign On Workflow
There are two variations on the SSO workflow, shown (in simplified form) to identifies the components, plus their role and location in the sequence.
Non-SSO Dynamic Modes
For all SSO modes except SSO Dynamic, the following is the (simplified) workflow:
1. The user either goes to the SharePoint web page with the SSO Authentication web part or is directed there if they are not logged onto Cognos.
2. The SSO Web Parts requests the current page URL (the SharePoint “internal” URL is returned) and retrieves user identity, which can be a “windows identity” (e.g. NTLM) or a “claims identity” (e.g. SAML/trusted claim, windows claim, forms claim, …)
3. The SSO Web part builds a redirection request to the Cognos Bridge Service via the Cognos Gateway with parameters including the user identity, and the current page URL (as the “endpoint URL” parameter), which is where the SSO workflow will return to on completion.
4. The Cognos gateway authenticates the user and passes the authentication token (Cognos “passport”) to the bridge service using the QvtSsoParams.xml file to provide which properties to pass (passport) and the url of the web component that the Cognos Bridge Service will redirect to (ssonrd.jsp), plus the “endpoint URL”
5. The ssonrd.jsp packages the passport and redirects to the “endpoint URL”
6. The passport is read from the response by the SSO Web Part
7. The page is updated showing the user logged in and rendered for the user
SSO Dynamic Mode
For SSO Dynamic, there is an addition component – a handover page (qvtSSODynamic.hml), which packages user identity and other parameters into [Browser] Cookies to permit downstream components (including the Trusted Sign On Provider [TSOP]) to access them in the context of the user/browser request.
1. The user either goes to the SharePoint web page with the SSO Authentication web part or is directed there if they are not logged onto Cognos.
2. The SSO Web Parts requests the current page URL (the SharePoint “internal” URL is returned) and retrieves user identity, which can be a “windows identity” (e.g. NTLM) or a “claims identity” (e.g. SAML/trusted claim, windows claim, forms claim, …)
3. The SSO Web part builds a redirection request to the qvtSsoDynamic.html page with parameters including the user identity, and the current page URL (as the “endpoint URL” parameter), which is where the SSO workflow will return to on completion.
4. The qvtSsoDynamic.html packages the parameters as cookies that components on the Cognos server can access (in the Cognos domain) and redirects to the Cognos Gateway requesting the “Cognos Bridge Service”
5. The Cognos gateway delegates request to the Cognos Access Manager to determine if the user/request is authenticated.
6. If the user/request is not authenticationed, the CAM directs to the designated (QueryVision supplied) Trusted Sign On Provider which “unpacks” the user identity and authenticates the user (details omitted)
7. Once authentication is complete, control is returned to the CAM
8. The CAM passes the authentication token (Cognos “passport”) to the Cognos Bridge Service using the QvtSsoParams.xml file to provide which properties to pass (passport) and the url of the web component that the Cognos Bridge Service will redirect to (ssonrd.jsp), plus the “endpoint URL”
9. The ssonrd.jsp packages the passport and redirects to the “endpoint URL”
10. The passport is read from the response by the SSO Web Part
11. The page is updated showing the user logged in and rendered for the user