Internal Use Cases
What this screen is for
An internal use case authorizes one of your applications to use a key on its own data, for example a service that encrypts records and later decrypts them. You name the application, the operations and the key. The platform then composes everything that authorization needs: a cryptographic actor, its client credential, an exchange context, and the capability grants for the operations you declared.
The use case references the key; it does not own it. The key stays in the Key Inventory with its own lifecycle, and nothing you do on this screen destroys key material.
A SIMPLE tenant composes all of its authorization here, because the screens that compose it by hand are not offered to SIMPLE tenants. A STANDARD tenant can use this screen too, as the short path for an application working on its own data, and composes flows between several parties on its other screens.
What must exist first
- An application in your tenant. Every use case belongs to exactly one application.
- Nothing else. A key is not a prerequisite: if you have no suitable one, you generate it inside the dialog, on the key step. What still holds is that a key's purpose has to fit the operations you declare — a key made to encrypt and decrypt cannot sign or verify, and a signing key cannot encrypt — and the dialog only offers, or generates, keys that fit what you ticked.
- The permission to read internal use cases, which is what shows this screen. Creating, suspending, resuming and revoking a use case are four further permissions, and each one can be held without the others.
Decisions you make here
Provisioning a use case
With the permission to create internal use cases, New Use Case asks for:
- A Name and an optional Description.
- The Application the authorization belongs to.
- The Operations the application may perform.
ENCRYPT,DECRYPT,SIGN,VERIFY,REENCRYPT,RESIGNandEXPORT_KEYwork on a key; the interoperability and PKCS#7 operations do not. The use case authorizes exactly what you tick, so declare only what the application needs. - The Key those operations run on. Only a key whose purpose admits every declared operation can be selected — and if none exists, Generate opens the same key-generation wizard the rest of the console uses, narrowed to the operations you declared.
- The key exists as soon as the wizard succeeds, not when you submit the use case: submitting creates no key of its own, and a failed submit has none to strand. The generated key stays in the Key Inventory with its own lifecycle even if you abandon the dialog, and nothing here deletes it.
- For
REENCRYPTorRESIGN, a Source key and a Target key (destination). Naming the same key for both is valid: that moves data from an older material version of the key to its current one under a single key identity.
When the use case is created, the client ID and client secret of its new credential are shown once. Store the secret in your secret store before you close the dialog. It cannot be shown again; if it is lost, rotate the credential to obtain a new one.
Suspending and resuming
With the permission to suspend internal use cases, suspending stops the workload at once. It is denied every cryptographic operation, a token it already holds is refused on its next call, and a request for a new token is refused. You must give a reason, which is recorded in the audit trail against your account.
Suspending keeps everything: the referenced keys and their material, the capability grants, the client credential and any federated identity bindings. In the rare case the change does not reach enforcement, containment converges within ten minutes.
With the permission to resume internal use cases, resuming restores the use case exactly as it was. Nothing is provisioned again, and the same credential works again.
Revoking
With the permission to revoke internal use cases, revoking is final. The cryptographic actor, its credential, the exchange context and every capability grant the use case composed are withdrawn, and the application stops being authorized for these operations immediately. A revoked use case cannot be resumed. The keys stay in the Key Inventory. A reason is optional and is recorded in the audit trail.
Suspend when you expect to restore the same authorization later. Revoke when it must never work again.
Rotating the credential and binding identities
Opening a use case shows its detail on four tabs: Overview, Access, Capabilities and Activity. The Access tab carries two decisions.
- With the permission to rotate actor credentials, Rotate… issues a new secret and shows it once. It changes what can obtain a new token; an access token already issued keeps working until it expires. Suspending the use case is what stops a token already in use.
- Under Federated identities, you can bind an external identity so the workload authenticates with a token from an issuer your tenant trusts instead of a secret held here. It needs the workload identity permissions, a tenant entitled to workload identity federation, and the issuer declared in your tenant's Settings. A binding conveys identity only and grants no capability.
While the use case is suspended or revoked, a credential issued or an identity bound on this tab cannot obtain a token. After a resume, both work.
The Capabilities tab shows what the use case authorizes and over which keys. The Activity tab needs the permission to read the audit trail. It shows your tenant's own administrative history for the use case; actions a platform operator took on your tenant's behalf are not listed there.
How it relates to other screens
The use case belongs to an application, and deleting that application revokes its use cases:
The actor, credential and grants a use case composes are the same kinds of object a STANDARD tenant composes by hand:
The keys a use case references live in the Key Inventory. A key outlives every use case that references it, and the Key Inventory warns you before you destroy a key a use case still references.