Relying party authentication flow

Relying Party authentication supports implicit flow and authorization code flow.

• Implicit flow is useful when you need to single sign-on from the internet to an intranet site. During the implicit flow, the /token endpoint is not needed, and no direct connection exists from the RP to the OpenID Provider (OP). This lack of direct connection is based on the assumption that no metadata or /userinfo is configured.
• Authorization code is traditionally considered to be more secure. It is the only instance where a refresh token might be issued. Both the ID token and access token are considered less at risk when the RP uses the authorization code flow, as neither is ever transported through the browser.

When a federated single sign-on is performed with the OpenID Connect (OIDC) Relying Party (RP), several steps must be completed. It is useful to understand these steps, so that you understand what potential customization can be made to the requested authentication.

1. The first step of an authentication is the kickoff, which is initiated by accessing the following URL:

   https://www.mywebseal.com/<isva junction>/sps/oidc/rp/<federation name>
   /kickoff/<partner name>

   For example, with a junction of /isva, a federation of my_federation and a partner of partner_company, the URL is:

   https://www.mywebseal.com/isva/sps/oidc/rp/my_federation/kickoff/partner_company

2. When the Kickoff request is first received, the federation and partner name are checked to ensure the request is for federation with a valid configuration. The OIDC OP metadata, if configured, is retrieved now.

   See Relying party authentication metadata.

3. If a Target query parameter was provided, it is stored in the user's session.
4. The incoming HTTP request is then serialized into an STSUniversalUser(STSUU). This structure contains any incoming request parameters. Any parameters that must be added to the request to /authorize are added to STSUU context attributes.
5. If an advanced mapping rule is configured, it is run now. This action occurs now so the authentication request to the OP can be modified at run time.

   See Relying party advanced configuration.

6. After the advanced mapping rule is invoked, the state and response_type are validated. When validated, they are persisted in the user session.

   See Manage Distributed Session Cache.

7. A response is then sent to the user agent, redirecting the user to the OIDC Provider (OP).
8. The OP completes its processing steps. Typically an authentication is performed, or a pre-existing session is checked, and potentially a prompt to consent is issued
9. When the OP processing completes, the user is redirected back to the RP, through the pre-registered redirect URI.

   This URI has the format:

   https://wwww.mywebseal.com/isvajct/sps/oidc/rp/<federationName>/redirect/<partnerName>

   For example, with the example values from above, the URL would be:

   https://wwww.mywebseal.com/isva/sps/oidc/rp/my_federation/redirect/partner_company

10. Next, the Redirect URI of the RP is invoked. This invocation occurs in one of the following ways:
    • If a GET request is serviced from the user agent, whether coming through a 302 from the OP or another method, and the state parameter is not included through a query string, then the RP sends back the self-posting form. The self-posting form extracts the fragment portion of the URL and posts the values to the RP. The self-posting form is the template page form_post.html. Use the local management interface to obtain this file. Access Federation > Global Settings > Template Files. The path to the file is C > oidc > rp > form_post.html.
    • If the request is a POST, the incoming parameters are validated and the single sign-on proceeds.
    • 302 including query string. In this case, the RP processes the query parameters. The OAuth RFC forbids this action when an access_token is included in the redirect.
11. Once the RP receives the redirect parameters from the OP, through one of the mechanisms above, the RP validates the request. The validation includes validating the state, and asserting the incoming request contains all of the response_types included in the request.
12. Next, the advanced mapping rule is invoked. This invocation can be used to perform an HTTP Callout, or to add more parameters to the /token or /userinfo requests (if configured).
13. When the request is validated, if an id_token was returned from the request, it is validated and decrypted. The claims and header of this JWT are added to the STSUU. The at_hash, nonce, and c_hash claims of the id_token are validated.
14. After the implicit id_token is validated, if a code was returned it is now exchanged at the token endpoint. The response is then validated and the response parameters are added to the STSUU context attributes.
15. The id_token that was returned from the token endpoint is then validated and decrypted, and its claims are checked.
16. If the RP is configured to access user information, and possesses an access token, it makes a request to /userinfo with the access token. The response is included in the STSUU attribute list. The sub claim that is returned is checked against the sub claim in the id_token.
17. The STSUU is now passed to the final identity map step, where the STSUU is processed into a credential. This step is performed by HTTP callout or JavaScript mapping rule, depending on configuration.

    See Relying Party identity mapping.

18. If you’re authenticating a user that does not exist in the Security Verify Access registry, the point of contact configuration must be updated to reflect this authentication.

    See Point of contact profiles for Federation.

Parent topic: Authentication with OpenID Connect Relying Party