Idea ID: 2800536

Request access for non human accounts (not tied to a human identity)

Status: New Idea

When requesting access for a service account, which is not for a specific person's use, the account would not be for a specific person's identity.

There should be a good design for accommodating these non human accounts into the product from requesting through reviewing the accounts access.

Parents
  • I see a couple of options. First, the ability to request accounts for applications without it being necessary for there to be an identity for that account. Second, would be to have different types of identities.

    If it is necessary to tie the request of a service account to an identity, identities will need to be given a classification such as internal employee, external partner/contractor, service accounts, devices, etc. This is likely already under consideration with the current thought leadership that, "Identities have evolved beyond heartbeats".

    Having types of identities will have implications throughout the system as some identity types may not be eligible for some roles. For instance, a service account should not be able to be specified as a review owner or reviewer. It may be necessary to configure which identity types can be used in certain roles. Identity Governance would need to only allow the configured identities to be selected for a specific role. For instance, only internal employees could be selected as review owners or only internal employees or external partners/contractors could be selected as reviewers.

    In addition, a request for these service accounts will need to give the option to populate the account custodian for the service account. Not all customers are using the custodian concept, though I expect more do so as it becomes a standard security practice.

Comment
  • I see a couple of options. First, the ability to request accounts for applications without it being necessary for there to be an identity for that account. Second, would be to have different types of identities.

    If it is necessary to tie the request of a service account to an identity, identities will need to be given a classification such as internal employee, external partner/contractor, service accounts, devices, etc. This is likely already under consideration with the current thought leadership that, "Identities have evolved beyond heartbeats".

    Having types of identities will have implications throughout the system as some identity types may not be eligible for some roles. For instance, a service account should not be able to be specified as a review owner or reviewer. It may be necessary to configure which identity types can be used in certain roles. Identity Governance would need to only allow the configured identities to be selected for a specific role. For instance, only internal employees could be selected as review owners or only internal employees or external partners/contractors could be selected as reviewers.

    In addition, a request for these service accounts will need to give the option to populate the account custodian for the service account. Not all customers are using the custodian concept, though I expect more do so as it becomes a standard security practice.

Children
No Data