Keycloak SSO, Authentication, and Authorization
Overview
Use this document to understand how P1 manages SSO, authentication, and authorization. In this document, you will learn how applications can integrate and consume user profiles from any request coming into their application.
JWT/Keycloak introduction
Mission applications must use the P1 Keycloak service for authentication. Teams should not deploy or manage their own Keycloak instances.
P1 Keycloak is automatically integrated into every mission application. No additional development work is required to enable this integration. P1 and Party Bus manage the service, including user access. If your application needs to add new users, you must submit a Keycloak support request through the P1 Help Desk .
P1 Keycloak does not support public clients. Client IDs and secrets are restricted and not provided to customers due to their sensitivity. In most cases, direct client integration is not required.
Applications are still responsible for authorization (RBAC). This can be handled by parsing the JWT in incoming requests, specifically the Authorization header. Additional details are provided below.
How does the Auth Flow work?
Here is a generalized workflow of how authentication and token validation are achieved.
What does my application's Keycloak group hierarchy look like?
Every application now uses a standardized group hierarchy in Keycloak.
How do I get users added to my Keycloak groups and create custom roles?
To add users to the above hierarchy or ask for a custom role to be added to an IL, submit a Keycloak support request through the P1 Help Desk . Submit one ticket with a complete list of users and the groups they should be added to. Do not submit separate tickets for individual users.
How can my app integrate?
By default, all mission workloads deployed to Party Bus will automatically be configured to authenticate against P1 SSO. What that means for you:
- It is safe to assume every request coming in is authenticated against P1 SSO.
- It is safe to assume the token has been pre-validated against the SSO public key.
- It is safe to assume the user making the requests is authenticated for the IL that your application is deployed to.
After the authservice successfully validates a request, it will set the Authorization: Bearer header on the request it passes to the application code. This header is in JWT format, can be parsed with any JWT library, and will contain the user's profile from Keycloak.
NOTE
If your application code uses the JWT HTTP header instead of Authorization, please update it to use Authorization. The JWT header has been deprecated to save header size.
redirect-uri
Configure the following redirect URI in your Keycloak client settings for both staging and production environments (aka the DNS entry provided). It is required for authentication responses.
oauth/callback
Party Bus Test Drive: AuthService emulation for local development
Party Bus Test Drive is an ecosystem of tools that help you quickly create a development environment that closely resembles the Party Bus platform. This helps your project get off the ground fast and simplifies migration into the Party Bus environment.
Party Bus Test Drive helps your application by setting up a single-point https-enabled ingress and injecting a JWT on every request to your microservices - all in your local development environment. This emulates the Party Bus AuthService process so you can write code in development that behaves the same in production, helping shorten development feedback loops.
TIP
Party Bus Test Drive can help you create new projects that are optimized for Party Bus using many common front-end and back-end tech stacks and databases.
UG - AuthService/JWT - Django implementation
You can use Django as the back-end for your REST API. It is essential to associate each user's request with their specific actions so that a mission commander can have a real-time overview of changes made to a mission. By implementing the authorization service, we can ensure that all users accessing the back-end are authenticated through the P1 SSO.
Decode the JWT for user information
The approved way to receive user information is to decode the JWT in the Authorization header. For Django and Python, we leverage the PyJWT library.
FAQ
What if the group structure doesn't meet my requirements?
The authentication JWT is included with every request and can be used for user authentication. If applications require role- or group-based authorization, this can be handled within the application.
Teams may store user roles and group assignments in their application database and use the user ID from the JWT to match and enforce access controls within their code.
How long are Keycloak sessions and JWT tokens valid?
Current Keycloak configuration includes:
- Session idle timeout: Approximately 3 hours (subject to change).
- JWT access token lifetime: Approximately 10 minutes.
The authentication service automatically renews access tokens as long as the user's Keycloak session remains active, so users do not need to reauthenticate when an access token expires.
INFO
Note: Session timeout values are under review to better align with ASD STIG requirements. Planned changes may reduce session idle time to approximately 15 minutes once testing is complete.
Does Keycloak use access and refresh tokens?
Yes. Keycloak uses a token renewal model where short-lived access tokens are automatically renewed for the duration of an active Keycloak session. Applications integrated with the platform's SSO do not rely on a single long-lived JWT.
Can I determine the token expiration from the JWT?
Yes. The JWT contains standard expiration claims (such as exp) that indicate when the current access token expires.
Do P1 accounts automatically expire after 35 days of inactivity to comply with ASD STIG requirements?
No. P1 accounts are not automatically disabled after 35 days of inactivity.
The platform records each user's last login as a user attribute. In the past, administrators manually disabled groups of inactive users based on their last login dates, but this is no longer performed as a routine automated process.
If your application must comply with ASD STIG account inactivity requirements, you should verify whether your team is responsible for implementing additional account management controls.
Does the system require X.509v3 certificates?
No. The system supports password plus OTP authentication as an alternative to X.509v3 certificates.
When do the certificates expire?
The realm token-signing keys expire on May 19, 2030. If this question refers to other certificates, ask for help in the Party Bus Value Stream Support channel .
Are the certificates issued by an approved certificate authority (for example, DoW, DAF, commercial, or local PKI)?
Yes. The certificates are primarily issued by the DoW PKI. A complete list of issuing certificate authorities can be provided upon request.
How does the system validate certificates?
The system validates certificates using the OCSP AIA method.
What directory service does the system use (for example, Active Directory, LDAP, or an internal access control list)?
The system does not use an external directory service. User accounts are managed internally in the Keycloak PostgreSQL database.