# `Ankusa.Admin.Auth.MTLS`
[🔗](https://github.com/jamescarr/ankusa/blob/ankusa-v0.7.0/packages/ankusa/lib/ankusa/admin/auth/mtls.ex#L1)

Mutual TLS (`mode: :mtls`): the identity is the client certificate the
listener's `tls: %{verify: :verify_peer}` handshake accepted
(`Ankusa.Listener`), so a request with no certificate or one from another CA
never reaches this module. What the certificate may do is configured:

    mtls: %{
      subject_map: %{
        "cn:ops-laptop" => ["dlq:read", "replays:write", "tenant:*"],
        "uri:spiffe://prod/ns/billing/sa/exporter" => ["metrics:read"]
      }
    }

A certificate offers identities of five forms, looked up in this order: its
subject alternative names (`dns:<name>`, `email:<address>`, `uri:<uri>`,
`ip:<address>`), then its subject common name (`cn:<name>`). The first one
in the map is the principal, named by that identity. A valid certificate none
of whose identities is mapped is `401`: the CA vouches for who it is, not for
what it may do.

# `identities`

```elixir
@spec identities(binary()) :: [String.t()]
```

The identities a DER certificate offers, in lookup order: subject alternative
names, then the common name. `[]` for a certificate that cannot be parsed.

---

*Consult [api-reference.md](api-reference.md) for complete listing*