add identity generators to decision api

[fspmarshall]

Adds methods to the decision service for generating simulated identities for use in auditing/introspection queries. I.e. if a user with sufficient privileges wants to inspect the result of decisions about a 3rd party but does not have access to that 3rd party's certificate, the user can instead invoke this API to get an approximation of what that user's identity object should look like. Ex:

rsp, _ := ctl.GetSimulatedSSHIdentity(ctx, decision.GetSimulatedSSHIdentityRequest{
    Username: "[email protected]",
  // ...
})

decision, _ := clt.EvaluateSSHAccess(ctx, decision.EvaluateSSHAccessRequest{
    SshIdentity: rsp.SshIdentity,
    // ...
})

In the future, the request objects will likely be augmented with additional parameters to simulate stateful identity elements such as access requests without needing to generate actual access requests.

This is an alternative to #50482

[codingllama]

I can see how this covers RequestIdentityMode.PARTIAL but what about RequestIdentityMode.CALLER_IDENTITY?

[fspmarshall]

We definitely can add a caller identity flag to the TLS identity getter. Unfortunately, caller identity isn't really possible for SSH. Given that, I was thinking that maybe it'd be more consistent to handle caller identity by just having the client-side parse the local certificate w/o calling the decision service.

WDYT? Better to shoot for consistency, or should we have a mix of caller identity flags and local parsing for the two identity types? (or some third option?)

[codingllama]

I don't think we should have client-side doing certificate->tlsca.Identity->decisionpb.TLSIdentity, it seems like a detriment for when we actually simplify certificates. At that point this should be Auth's (and/or Proxy's) attribution and no one else's.

[fspmarshall]

Hmm, if we want to take a hard line against client-side parsing, should we just have a bytes cert field as an alternative to the username? That'd keep ssh/tls identities consistent & keep all identity parsing server-side.

[codingllama]

The username likely comes from a command line invocation, no? tctl decision-service evaluate-database --user=llama --db-user=admin --db-name=mydb ....

Regardless of source, querying the accesses of a user is a task that makes sense. I don't see how an opaque cert field helps that.

[fspmarshall]

Sorry, I'm not explaining myself well, and kind of mixing two different discussions/questions.

Question one: how do we handle SSH identities for a "use my current identity" feature? The "caller identity" strategy is a valid way to implement that feature for TLS, but we need an SSH equivalent. My first thought was to parse the ssh cert client side. My follow-up suggestion was to send it to the decision service as a parameter in the request, specified instead of username.

Question two: Assuming we have a working solution for "use my current identity" for SSH, should we still bother having a separate "caller identity" feature just for TLS, or should we keep it consistent and just do whatever we did for SSH for the TLS certs too?