Service Identities

Prev Next

Service identities are non-human identities used for non-interactive use cases like automation, scripting, etc. 

Service/AI identities can use authentication in the following ways:

  • Static: This uses SAML 2.0, and a token for a service/AI identity is created with a validity date.

  • Federated:

Prerequisites for OIDC providers

You need the following information before configuring an OIDC identity provider:

  • Issuer Url: This needs to be unique within a tenant. For more information about the issuer URL and how to retrieve it from the ID Token, see OIDC issuer URL documentation.

  • Allowed Audience: This is a value agreed upon between a client of the OIDC provider and the OIDC provider. For more information about the audience located in the ID Token, see Allowed Audience.

Prerequisites for AWS STS providers

You need to generate an AWS STS token for Britive to consume. For more information about generating AWS STS tokens, see CLI application  or GetCallerIdentity.

Creating Service Identities

  1. Log in to Britive with administrator privileges.
  2. Click Admin -> Identity Management.
  3. Select the Service Identities tab and click on the Add Service Identity button.
  4. Enter the following on the Add Service Identity page:
    1. Enter the Name and Description of the service identity.
    2. Select the Access Type. 
      1. Static: Enter Token Validity in days. This is the duration of the workload token. 
      2. Federated: 
        1. Select the identity provider from the list. Make sure you have an identity provider created and configured already. For more information, see Identity Providers.
        2. Enter Token Validity in seconds. This is the duration of the workload token and depends on the type of identity provider. For more information, see Token Validity.
        3. Add Federated Attributes. These are used to map service identities that the token is for. These attributes are defined while creating/managing an identity provider.
        4. Add information about the kind of service identity in the Category text box.
        5. Enter the Business Use description.
    3. Click Add. For Static authentication, a token is created and displayed. Copy and save the token.

Token Validity

The duration of the workload token depends on the type of identity provider token being used. Each service or AI identity, when selecting the workload identity provider to associate, can configure the token duration in seconds of the tokens issued by the identity provider.

  • OIDC: The ID Token duration is the lesser of the duration between the current date/time the ID token is being validated and the ID Token’s expiration date claim (exp) and the mapped service/AI identity’s configured token duration when the OIDC provider is assigned.

  • AWS STS: The AWS token validity period is determined by the lesser of the AWS identity provider configured maximum token validity period, the service/AI identity configured token duration in seconds for the assigned identity provider, and the duration between the current time the token is first validated and the expiration time in the AWS “token” if requested.

Validation Window

A validation window is configured for each workload identity provider, specifying the amount of time in seconds after the workload identity token was issued/signed, and the Britive app verifies the token is valid. Once verified/validated, the token is considered valid until the token's validity period expires as specified in the Token Validity.

Managing Service Identities

  • Edit: You can edit any Static or Federated service identity parameters. 
    • Switch access by clicking the Switch Access button on the Edit page. This switches access from Static to Federated or vice versa. 
    • For static service identities: Reset the token and change the validity of tokens from the Edit page.
    • For federated service identities: Change the identity provider, token validity period, and federated attribute values.
    • Owner: Grant ownership of service/AI identity to users and/or tags by clicking Select Users or Select Tags.
    • On Behalf of: Configure a non-human identity such as a service Identity to act on behalf of a user (user/tag that user is part of) using the On-Behalf-Of (OBO) flow, allowing the service to execute operations within the user’s security context while preserving their identity, permissions, and audit visibility. A profile must also have the Allow Impersonate setting enabled for this to work. For more information on configuring this, see Britive Profile Management.
    • Edit custom attributes. These are used to map service identities that the token is for. These attributes are defined while creating/managing an identity provider.
  • Disable Identity: If this identity is assigned to one or more profiles, disabling it automatically unassigns it from all the associated profiles.
  • Delete Identity: If this identity is assigned to one or more profiles, deleting it automatically unassigns it from all the associated profiles.

Use case of OIDC provider

The following section describes an end-to-end use case for configuring OIDC provider, Britive service identities, and how to use it by checking out a Britive profile.

  1. Create an OIDC IdP using this procedure: Creating Identity Providers.
  2. Create a service identity and associate it with an OIDC IdP.  See Creating Service Identities to create service identities.
  3. Configure the attribute map such that ID Token's attributes are mapped to the Britive service identity. For example, Britive custom attribute OIDC subject mapped to subject claim in the ID token.
  4. Enter Allowed audiences. This can be retrieved from the ID Token of an OIDC provider. See the Prerequisites section for details.
  5.  Get Federated Attributes. For example, the user name and repository name, and branch for GitHub.
  6. Create a profile for an AWS application. Add a service identity in that policy to get access to the checkout that profile.  Profile -> Permissions -> Policy -> Add service identities. For more information, see Managing Profiles.
  7. When calling Britive APIs with OIDC providers, make sure to use the OIDC token prefix in the authorization header Authorization: OIDC::{{ID Token}}.

Use case of AWS STS provider

The following section describes an end-to-end use case for configuring AWS STS provider, Britive service identities and how to use it by checking out a Britive profile.

  1. Create an AWS STS identity provider using this procedure: Creating Identity Providers.
  2. Create a service identity and associate it with the AWS STS identity provider.  See Creating Service Identities to create service identities.
  3. Configure the attribute map such that the ID Token's attributes are mapped to the Britive service identity.  Map Account, Arn, and UserId from the ID token to Britive custom attributes. For more information on how to retrieve attributes from the token, see GetCallerIdentity.
  4. Create a profile for an AWS application. Add a service identity in that policy to get access to the checkout that profile.  Profile -> Permissions -> Policy -> Add service identities. For more information, see Managing Profiles.
  5. When calling Britive APIs with OIDC providers, make sure to use the OIDC token prefix in the authorization header Authorization: AWS::{{ID Token}}.Token Validity