Example flow for anonymous users

The following diagram identifies the flow of authentication and authorization information for unauthenticated callers. Colors are used in the following ways:

  • Orange - credentials information
  • Blue - endpoint access information
  • Green - resource access information
  • Red - proxy user and session user information

Some values are used to determine multiple types of access. These values initially appear as black (when they do not apply to a single type of access), and then later appear in one or more specific colors (to reflect the value is being used at that point in the process for a specific type of access).

The anonymous user flow always involves multiple calls.

  • For the initial call that starts a new session and creates the account, the user is unauthenticated.
  • If a call is sent to create a new session to continue work from a previous session, the user is unauthenticated.
  • For all other calls in an existing session, the user is anonymous.

The initial call as an unauthenticated user

In the following example, an API call is triggered by an unauthenticated caller who creates an account and later plans to bind a policy submission.


First authentication flow for unauthenticated callers
  1. The user triggers an API call by creating a new account. The caller application sends the API request to PolicyCenter. The call includes no JWT, and no authentication information in the header.
  2. The IExpandTokenPlugin plugin is not relevant for anonymous users.
  3. Because the call has no authentication header, PolicyCenter grants endpoint access as defined in the Unauthenticated.role.yaml API role file.
  4. Because the call has no authentication header, PolicyCenter grants resource access as defined in the unauthenticatedUser.access.yaml API role file. (This provides no access to existing business resources.)
  5. To determine which proxy user to assign to the session, PolicyCenter calls the RestAuthenticationSourceCreator plugin. The call has no authentication header. So, the plugin returns the proxy user for unauthenticated users: uauser.
  6. PolicyCenter processes the request.
    1. The session user is the proxy unauthenticated user: uauser.
    2. The endpoint access is defined by Unauthenticated.role.yaml. (This API role provides sufficient endpoint access to create a new account and the required child objects, such as contacts and locations.)
    3. The resource access is defined by unauthenticatedUser.access.yaml.
  7. PolicyCenter provides the response to the initial call. The response includes the account number for the newly created account (464778619) and a self-signed JWT generated by PolicyCenter. The JWT includes the client ID (cid), a scp token claim which names the resource access strategy (pc_accountNumbers) and additional deployment information, a groups token which names the user's groups (gwa.prod.pc.anonymous), and a pc_accountNumbers token which names the user's resource access IDs (464778619).

A subsequent call to reauthorize an unauthenticated user

In the following example, an API call is triggered by an unauthenticated caller who has already created an account and started a submission at some previous point in time.


Second authentication flow for unauthenticated callers
  1. The user triggers an API call to complete a previously initiated submission for an existing anonymous user account. The caller application sends the API request to PolicyCenter using the /recover-new-jobs endpoint as configured by the insurer. The call includes search criteria configured by the insurer (such as an account number or user name), but it has no JWT and no authentication information in the header.
  2. The IExpandTokenPlugin plugin is not relevant for anonymous users.
  3. Because the call has no authentication header, PolicyCenter grants endpoint access as defined in the Unauthenticated.role.yaml API role file.
  4. Because the call has no authentication header, PolicyCenter grants resource access as defined in the unauthenticatedUser.access.yaml API role file.
  5. To determine which proxy user to assign to the session, PolicyCenter calls the RestAuthenticationSourceCreator plugin. The call has no authentication header. So, the plugin returns the proxy user for unauthenticated users: uauser.
  6. PolicyCenter processes the request.
    1. The session user is the proxy unauthenticated user: uauser.
    2. The endpoint access is defined by Unauthenticated.role.yaml. (This API role provides sufficient endpoint access to create a new account and the required child objects, such as contacts and locations, and to complete a submission.)
    3. The resource access is defined by unauthenticatedUser.access.yaml.
  7. PolicyCenter provides the response to the initial call. The response includes the unbound submissions that meet the search criteria provided with the initial call. It also includes a new self-signed JWT generated by PolicyCenter. As was the case with the first self-signed JWT, this JWT includes the client ID (cid), a scp token claim which names the resource access strategy (pc_accountNumbers) and additional deployment information, a groups token which names the user's groups (gwa.prod.pc.anonymous), and a pc_accountNumbers token which names the user's resource access IDs (464778619).

The later call as an anonymous user

After a previous call to create an account or recover an unbound submission, another API call is triggered by the previously unauthenticated caller who is now anonymous. This call creates and creates, modifies, or binds a policy submission.


Second authentication flow for unauthenticated callers
  1. The user triggers an API call by attempting to create, modify, or bind a submission. The caller application sends the API request to PolicyCenter. The call includes the self-signed JWT.
  2. The IExpandTokenPlugin plugin is not relevant for anonymous users.
  3. PolicyCenter determines the endpoint access. Based on the groups listed in the JWT (gwa.prod.pc.anonymous), the anonymous.role.yaml API role file is used to define the endpoint access.
  4. Next, PolicyCenter determines the resource access strategy. Based on the resource access strategy value in the JWT (pc_accountNumbers), it grants resource access as defined in the accountholder.access.yaml files. (* PolicyCenter starts with accountholder_ext-1.0.access.yaml, but this file references additional access.yaml files whose name starts with "accountholder".)
  5. To determine which proxy user to assign to the session, PolicyCenter calls the RestAuthenticationSourceCreator plugin. The JWT specified a resource access strategy of pc_accountNumbers. So, the plugin returns the proxy user for external users: extuser.
  6. PolicyCenter processes the request.
    1. The session user is the proxy external user: extuser.
    2. The endpoint access is defined by anonymous.role.yaml. (This API role provides access to actions appropriate for anonymous users, such as quoting and binding submissions.)
    3. The resource access is defined by accountholder.access.yaml.
  7. PolicyCenter provides the response to the call.

If the anonymous user's policy is bound, then the user becomes "known" to the insurer. At some point in the future, the user's information is sent to the IdP. Once this occurs, the user will be treated as an external user.