No Documentation on callback URL for OIDC about ssh-inscribe

[aakso]

Hey,

Thanks for reaching out. Yeah, this is something that isn't documented. I'm happy to accept any PRs to improve docs per provider basis. Right now I don't have a production setup using the OIDC auth mechanism.

However, previously I have used Google and Microsoft ADFS successfully.

Here is an example configuration for google:

authoidc:
  name: google
  realm: my google auth
  timeout: 15
  clientID: REDACTED.apps.googleusercontent.com
  clientSecret: REDACTED
  authFlowTimeout: 240
  maxPendingAuthAttempts: 1000
  scopes:
  - openid
  - email
  - profile
  redirectURL: https://localhost:8540/v1/auth_callback/google
  providerURL: https://accounts.google.com
  valueMappings:
    subjectNameField: name
    subjectNameTemplate: '{{.}}'
    principalsField: email
    principalTemplate: '{{.}}'
  principals: []
  criticalOptions: {}
  extensions:
    permit-pty: ""
    permit-user-rc: ""
    permit-agent-forwarding: ""
    permit-X11-forwarding: ""

So your question was about redirectURL. As you probably know this is the URL the auth provider will send the client to. We'll need to point it to the running ssh-inscribe daemon in order to validate the auth flow.

So for development I have set it to locahost here. The path part is important: /v1/auth_callback/{{nameOfTheAuthenticator}}.
If you are running the ssh-inscribe behind a load balancer you must devise a way to route the client to the same instance where the auth flow was started. If you only have a single instance, you can just set the redirectURL to the public hostname (and port) of the ssh-inscribe daemon. The only important thing is that the redirectURL must point to the current instance of the ssh-inscribe daemon.

Other config values include:

• timeout: timeout of the request(s) to OIDC provider
• authFlowTimeout: how long the started auth flow is kept in memory before evicting. The authentication must be completed in this time
• maxPendingAuthAttempts: how many pending auth attempts to hold in memory
• valueMappings.subjectNameField: from which jwt claims field to get the subject
• valueMappings.principalsField: from which jwt claims field to get the principals. This accepts either a single value of array of values in the JWT claim.
• valueMappings.subjectNameTemplate: allows mutating the value from JWT using go template
• valueMappings.principalTemplate: same thing as above from principals

Hope this helps. If you are willing, please do document your experience with Keycloak. That could benefit other users.

Anton Aksola