Scenarios
These scenarios walk you through the sample code and what happens when you run the sample.
- Administrator installs, or the user navigates to, partner application.
- Redirect started because the user attempting to access to SuperOffice functionality has not been authenticated.
- User is redirected to SuperID with client ID for authentication.
- SuperID successfully authenticates the user and then sends them to the partner applications redirect URL.
- Partner application receives SuperID request and JWT token. Validated using certificates.
- Partner application processes/configures user and stores system user token in the database.
- Partner service polls database for new tenant user tokens.
- Partner service signs user token with private key and sends it to SuperID to exchange for a system user ticket.
- Partner service validates system user token using certificates.
- Partner service calls tenant web services using the system user ticket.
Application code
The default page displays two action links.
Create company with login user
The first link uses the current users' SoSession (Principal Context) to create a new company in the tenant SuperOffice. This is standard functionality used to contrast how to perform the same operation as a system user.
Create company with system user
The second link uses a system user token to get a system user ticket, and then uses the system user ticket to authenticate and create a new company in the tenant database.
Caution
This scenario is not the recommended way to leverage a system user in an application. Threading with a NetServer SoSession instance is a complex topic, and it is only here in this example as a demonstration of signing the token, sending the signed token to SuperID, and then validating the returned JWT token containing the system user ticket.
The preferred way to use a system user token is demonstrated in the System Console project.
