As per the Toolkit documentation we set an external login process. In this case we are going to create /authorize/smlogin, as a modification of the /authorize/login process. So we modify the policy : '#OTK Authorization Server Configuration" to point to our smlogin page.
We then copy the login policy and save it as smlogin :
A good tip for viewing the policy is the have the "Show Comments" and "Show Assertion Numbers" checked - particularly for the OTK, as it has quite a number of comments & labels.
We do however need to modify "OTK User Authentication Extension" : Here we need to comment out lines 7 and 8 (since we are validating via SMSESSION cookie, so will not have username and password). Then lines 23 - 38 are as documented in the API Gateway manual for SSO integration for SMSESSION. Most of these were here already, but we changed 27 : "Authenticate against CA Single Sign On" to accept a cookie as well.
The modified "Authenticate against CA Single Sign On" at line 27:
Using the "Basic Client Profile" in "OAuth V2 Clients" here is the network trace of the /authorize process : We can see bcp click then does a GET for /authorise, which redirects to /smlogin, which then redirects to login.fcc. After we enter UN/PW on the login.fcc page, and do a POST back to login.fcc, Single Sign On authenticates the user sets an SMSESSION cookie, and redirects back to the /smlogin process on the API Gateway, which now passes the smlogin?action=login. We then drift through the consent page and then back to the bcp page with the authorization_code. The bcp page the makes backchannel calls to get the details of the tokens and claims.
One extra condition is - what if we already have a SSO SMSESSION cookie. In that case rather than doing the action=display task, we can skip and directly do the action=login task. However if we fail (perhap the SMSESSION is expired for example) then we would then want to default to doing the action=display, so that we process the login via the login.fcc page as normal. There are a few ways to solve it, here we created a display-login task, that is essentially a copy of the login task, but checks that the action=display at line 44. And where rather than error condition at 194, we allow the display-login branch to fail if the Authentication fails. So if the pre-display task fails, then it will try processing the 2nd in the "At least one of" list, and we will then process the action=display as normal.This way we try to login, and if the user already has an existing valid SMSESSION cookie, then we skip the login page entirely and go directly onto the consent page.
Clearly there are some more setup steps required. Such as setting up the resource as protected in the Single SIgn On world, and registeringthe API Gateway as SSO agent with the SSO policy server. Also in the xml samples uploaded it is coded to skip the consent screen. It still goes through the consent page, but does so with a "grant" setting directly rather than the "prompt" setting which prompts the user - that was just a requirement for this particular example.
Hope that helps with your setup. Cheers - Mark