Almost all requests to Conjur services require authentication.
Conjur can authenticate both users and "robots"("hosts") such as virtual machines, processes, and jobs.
Any entity (either host or user) has it's own unique API key which is used along with the id for authentication.
An API key is an alphanumeric string with length of 51 to 56 characters. It is generated randomly during identity creation, and can be rotated at a later time.
In addition, users may have passwords (but by default they do not). A user can be assigned a password during user creation, or at any later time via the update password command. Passwords can be used interchangably with the API key for purposes of conjur authn login. The differences between the password and API key are:
- The password is stored using bcrypt on the Conjur server. It cannot be recovered, only reset by the user.
- When the password is changed, the API key is rotated. The API key cannot be changed by a user to any predefined value, it's always a random string.
- Authentication by API key is somewhat faster than authentication by password.
A User can change their password at any time using the update password command. The API key is rotated as a side-effect.
When an identity is successfully authenticated, Conjur issues an expirable authentication token. The token is cryptographically signed by a Conjur private key, and it includes host/user id along with expiration timestamp. Almost all calls to Conjur (see a list of exceptions below) must include a valid authentication token. Any server requests will be rejected immediately unless both of conditions are true:
- The token is not expired.
- The token signature can be verified by the server.
Typically, an end-user of the CLI does not need to worry about authentication token mechanics, since each CLI command automatically obtains a token using cached login information, and passes it with each HTTPS request.
When using the Ruby API, a new API object can be instantiated from a API key or password and it automatically obtains a token. After token expiration, a new API object must be created or the server will start to reject the requests.
IP range limiting can be applied to specific machine and user identities to restrict authentication to specific network locations. For example, IP restrictions will prevent a malicious program or administrator from harvesting an API key from an operational server and then using it from a different network location such as a personal workstation.
Users can be created with an IP authentication restriction. For example:
$ conjur user create --as-group security_admin -p bob@demo --cidr 192.168.101.1
Now, when Bob attempts to authenticate the request must originate from 192.168.101.1
Create a user with a CIDR range authentication restriction:
$ conjur user create --as-group security_admin -p bob@demo --cidr 192.168.0.0/16
Restrict user authentication to multiple IP’s:
$ conjur user create --as-group security_admin -p bob@demo --cidr 192.168.101.10,198.51.100.1
Add IP authentication restriction to an existing user:
$ conjur user update --cidr 192.168.101.10 bob@demo
If an IP authentication restriction is added to an existing user with an existing authentication restriction, the existing restriction will be overwritten.
Requests bearing a Host Factory Token can be restricted in the same way.
In Conjur HA mode, any Conjur server (master or follower) can issue an authentication token which will be accepted by any other server.
During login, either performed with password or API key,
authentity of the user/host is checked with Conjur, and the identity id along with API key are stored in the
operating system user's
(or the file to which optional directive
.conjurrc points to).
On subsequent calls, the CLI automatically generates authentication tokens from the id and API key stored in
Performing login again will completely overwrite any previously cached credentials.
CLI command logout removes appropriate credentials from