Bring back ability to parse the realm of an incoming ticket

[danielcrenna]

Is your feature request related to a problem? Please describe. We have a gateway responsible for dispatching requests to downstream systems using KerberosClient. The general process has been to use an older version of this codebase via KerberosRequest to parse the incoming Negotiate header and determine which client to call by locating the Realm in various places like the MechToken, depending on the request type. The new version of the library requires a validator first, which is the step we take after we determine the realm, so we can't upgrade to the latest version.

Describe the solution you'd like I'd like either a facility like the previous code, or instructions/guidance on how to achieve the same result of determining the realm so our service can look up the appropriate validator and validate it. Worst case, I'd have to write my own AsnReader based solution to hand parse the token, which is not ideal considering the various ASN formats for KRB_AP_REQ.

Describe alternatives you've considered Our environment is such that we can't do the right thing and dispatch the calls directly to the downstream services, otherwise we wouldn't need to do this. However, it would be nice to be able to upgrade the library as part of a multi-step plan to remove the need for it, and the previous library did let us find the realm before creating a validator.

[SteveSyfuhs]

Can you share how you were calling the original KerberosRequest? I didn't think we removed anything that would prevent you from reading the realm name.

[danielcrenna]

Sure, it's fairly trivial. I just don't see an equivalent means of parsing a ticket before needing KerberosValidator/KerberosAuthenticator, but we need to look up the credentials by realm before we can get to that step.

KerberosRequest request = KerberosRequest.Parse(ticketBytes);
if (request.Request != null)
{
    return request.Request.Ticket.Realm;
}
if (request.NegotiationToken != null)
{
    return request.NegotiationToken.MechToken.InnerContextToken.Ticket.Realm;
}

[SteveSyfuhs]

Ah. Yeah, it moved into a more token-agnostic parser to handle all the different ways a Kerberos AP-REQ can be represented. The information is all there, but you have to dig a bit to get it.

I haven't tested this, but this should work for you.

private static string GetTicketRealm(string encoded)
{
    var bytes = Convert.FromBase64String(encoded);

    var request = MessageParser.ParseContext(bytes);

    while (request != null)
    {
        if (request is NegotiateContextToken nego)
        {
            var mechToken = nego.Token.InitialToken.MechToken;

            request = MessageParser.Parse<ContextToken>(mechToken.Value);
        }
        else if (request is KerberosContextToken kerb)
        {
            return kerb.KrbApReq.Ticket.Realm;
        }
        else
        {
            request = null;
        }
    }

    return null;
}

[danielcrenna]

@SteveSyfuhs Thank you for the example, this worked great.