opkssh
opkssh
This integration guide is community supported. It's not guaranteed to be complete, accurate, or up-to-date. It's likely that if this integration guide does not work for you that changes occurred with a third-party application.
Important Note: This documentation is version specific. Make sure you check the section outlining the tested versions.
Important Note: We always recommend users read the third-party documentation as part of the integration process to ensure configuration elements matches their needs. As such the See Also section is likely to have important links.
Important Note: If you find an error in this documentation please make a Pull Request, start a Discussion, or contact us on a Chat Room.
Tested Versions
Before You Begin
Important Reading
This section contains important elements that you should carefully consider before configuration of an OpenID Connect 1.0 Registered Client.
Common Notes
- The OpenID Connect 1.0
client_id
parameter:- This must be a unique value for every client.
- The value used in this guide is merely for readability and demonstration purposes and you should not use this value in production and should instead utilize the How do I generate a client identifier or client secret? FAQ. We recommend 64 random characters but you can use any arbitrary value that meets the other criteria.
- This must only contain RFC3986 Unreserved Characters.
- This must be no more than 100 characters in length.
- The OpenID Connect 1.0
client_secret
parameter:- The value used in this guide is merely for demonstration purposes and you should absolutely not use this value in production and should instead utilize the How do I generate a client identifier or client secret? FAQ.
- This string may be stored as plaintext in the Authelia configuration but this behaviour is deprecated and is not guaranteed to be supported in the future. See the Plaintext guide for more information.
- When the secret is stored in hashed form in the Authelia configuration (heavily recommended), the cost of hashing can, if too great, cause timeouts for clients. See the Tuning the work factors guide for more information.
- The configuration example for Authelia:
- Only contains an example configuration for the client registration and you MUST also configure the required elements from the OpenID Connect 1.0 Provider Configuration guide.
- Only contains a small portion of all of the available options for a registered client and users may wish to configure portions that are not part of this guide or configure them differently, as such it’s important to both familiarize yourself with the other options available and the effect of each of the options configured in this section by looking at the OpenID Connect 1.0 Clients Configuration guide.
Assumptions
This example makes the following assumptions:
- Authelia Root URL:
https://auth.example.com/
- Client ID:
opkssh
Some of the values presented in this guide can automatically be replaced with documentation variables.
Configuration
Authelia
Important Note
At the time of this writing this third party client has a bug and does not support OpenID Connect 1.0. This configuration will likely require configuration of an escape hatch to work around the bug on their end. See Configuration Escape Hatch for details.
The following YAML configuration is an example Authelia client configuration for use with opkssh which will operate with the application example:
identity_providers:
oidc:
## The other portions of the mandatory OpenID Connect 1.0 configuration go here.
## See: https://www.authelia.com/c/oidc
clients:
- client_id: 'opkssh'
client_name: 'opkssh'
public: true
authorization_policy: 'two_factor'
require_pkce: true
pkce_challenge_method: 'S256'
redirect_uris:
- 'http://localhost:3000/login-callback'
- 'http://localhost:10001/login-callback'
- 'http://localhost:11110/login-callback'
scopes:
- 'openid'
- 'profile'
- 'email'
- 'offline_access'
response_types:
- 'code'
grant_types:
- 'authorization_code'
- 'refresh_token'
access_token_signed_response_alg: 'none'
userinfo_signed_response_alg: 'none'
token_endpoint_auth_method: 'none'
Configuration Escape Hatch
Potential Escape Hatch Configuration Required
Unfortunately at the time of writing this integration this client does not support OpenID Connect 1.0. Fortunately Authelia has implemented an escape hatch that works for most clients which don't properly support OpenID Connect 1.0. This requires additional configuration to that which is described above. You can read more about this in the OpenID Connect 1.0 Claims Guide.
Clients are required to operate under the assumption that claims requested by scope values are available by using the Access Token (the scope is granted and issued to the Access Token) at the UserInfo Endpoint as described by 5.4. Requesting Claims using Scope Values with the exception of an Implicit Flow that does not return an Access Token, or explicitly request them via the claims parameter as described by 5.5. Requesting Claims using the "claims" Request Parameter .
The requirement to use this option is also often a clear indication the client also ignores the
claims stability requirements
which only allows clients to anchor accounts via the sub
and iss
claims. Ignoring this
requirement is likely a significant security issue as any provider that allows changing the claims
they use instead of sub
and iss
may inadvertently provide full administration access
to unprivileged users.
Both of these elements are clear indications the client does not properly support OpenID Connect 1.0 and is not conformant.
The following is an example of adaptation to the above configuration that works around the fact this client does not support OpenID Connect 1.0:
identity_providers:
oidc:
claims_policies:
opkssh:
id_token: ['email']
clients:
- client_id: 'opkssh'
claims_policy: 'opkssh'
Application
To configure opkssh to utilize Authelia as an OpenID Connect 1.0 Provider:
Server
To configure opkssh there is one method, using the Configuration File.
Configuration File
Did you know?
Generally the configuration file is named /etc/opk/providers
.
To configure opkssh to utilize Authelia as an OpenID Connect 1.0 Provider, use the following configuration:
https://auth.example.com/ opkssh 24h
In addition to above, the CLI will need to be used to map users manually.
For example allow the user john@example.com
to login as root
:
opkssh add root john@example.com https://auth.example.com/
Client
To log in using Authelia run:
opkssh login --provider=https://auth.example.com/,opkssh
Configuration File
Did you know?
Generally the configuration file is named ~/.opk/config.yml
on Linux and C:\Users\{USER}\.opk\config.yml
on Windows.
To create a persistent configuration, generate a new configuration file by running the following command:
opkssh login --create-config
Then add Authelia to the existing providers:
providers:
- alias: authelia
issuer: https://auth.example.com
client_id: opkssh
scopes: openid offline_access profile email
access_type: offline
prompt: consent
redirect_uris:
- http://localhost:3000/login-callback
- http://localhost:10001/login-callback
- http://localhost:11110/login-callback
You can now run opkssh login
to login.