Unclear who is responsible for holding user identifying information

[jnschaeffer]

There are some cases where we want to retain information about subjects, such as email address and name. For example, if a user named "Foo Bar" has logged into a portal, they will likely want to see that they are logged in as "Foo Bar" and not urn:infratographer:something/long. This possibly implies that at some stage during token exchange, we collect information about subjects when we know the issuer is an OIDC provider and store that somewhere (possibly in another service). Other questions come from this as well, such as:

• How can we provide identifiers for users such that an administrator can grant access to a known person, not just a long string that was possibly generated via claim mapping?
• Does identity-manager-sts generate (or fetch) UUIDs for all subjects it encounters?

It's not clear if identity-manager-sts or some other service would handle this logic, or what the requirements would be around making it available to users via an API.

[JAORMX]

@jnschaeffer if we're making the statement that IM-STS is ultimately the source of truth for identity in infratographer, then it makes sense to initially gravitate that data into IM-STS.

In an initial implementation, I think it's sufficient to rely on long strings for permission grants.

However, I understand this is not a very user-friendly mechanism for administrators. Thus, we should consider adding constructs for IM-STS to allow for an authorization service to make translations or simply fetch the information needed to make the subject translation itself (see my comment in https://github.com/infratographer/identity-manager-sts/pull/40/files#r1105618649 ).

Regardless, if we are going to start handling user identifying information (which is PII), we should ensure that we're following best practices and existing compliance standards.

@jnschaeffer @adammohammed thoughts?

[jnschaeffer]

@JAORMX We started work on handling this in an OIDC-friendly way in #32, so an issued access token can be used to get profile information about the user that the token belongs to. This information is sourced from the issuer and cannot be updated currently. I'm wondering if SCIM would be an appropriate mechanism for handling these kinds of flows, as it would allow issuers to integrate their user lifecycle management into Infratographer services.

I covered a bit of the SCIM logic idea at the end of the user model document in #62, but really that's a question of whether we provide our own custom API for user management or just standards-based APIs to facilitate cross-domain IAM (which is ultimately what IM-STS is built around).