Keycloak
Fleeting- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/user-federation.html
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/sessions/offline.html
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/groups/groups-vs-roles.html
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/groups.html
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/roles/client-roles.html
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/clients/installation.html
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/clients/protocol-mappers.html
- Référence externe : https://www.janua.fr/keycloak-access-token-verification-example/
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/sso-protocols/oidc.html
- Référence externe : https://www.keycloak.org/docs/latest/authorization_services/
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/overview/concepts.html
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/roles/client-scope.html
- Référence externe : https://www.keycloak.org/getting-started/getting-started-docker
- Référence externe : https://www.keycloak.org/
- Référence externe : https://wjw465150.gitbooks.io/keycloak-documentation/content/securing_apps/topics/oidc/oidc-generic.html
A very popular IdP and IAM. It supports OpenID Connect as built-in, then it can be called an
A realm in Keycloak is the equivalent of a tenant. It allows creating isolated groups of applications and users
— https://www.keycloak.org/getting-started/getting-started-docker
Add authentication to applications and secure services with minimum fuss. No need to deal with storing users or authenticating users. It’s all available out of the box.
hen an OIDC access token or SAML assertion is created, all the user role mappings of the user are, by default, added as claims within the token or assertion. Applications use this information to make access decisions on the resources controlled by that application.
Client scope is a way to limit the roles that get declared inside an access token
access token they receive back will only contain the role mappings you’ve explicitly specified for the client’s scope
default, each client gets all the role mappings of the user.
change this default behavior, you must explicitly turn off the Full Scope Allowed switch and declare the specific roles you want in each individual client
roles
Roles identify a type or category of user. Admin, user, manager, and employee are all typical roles that may exist in an organization. Applications often assign access and permissions to specific roles rather than individual users as dealing with users can be too fine grained and hard to manage
user role mapping
A user role mapping defines a mapping between a role and a user. A user can be associated with zero or more roles. This role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on various resources they manage.
groups
Groups manage groups of users. Attributes can be defined for a group. You can map roles to a group as well. Users that become members of a group inherit the attributes and role mappings that group defines.
realms
A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control
clients
Clients are entities that can request Keycloak to authenticate a user. Most often, clients are applications and services that want to use Keycloak to secure themselves and provide a single sign-on solution. Clients can also be entities that just want to request identity information or an access token so that they can securely invoke other services on the network that are secured by Keycloak
client adapters
Client adapters are plugins that you install into your application environment to be able to communicate and be secured by Keycloak
client role
Clients can define roles that are specific to them. This is basically a role namespace dedicated to the client
identity token
A token that provides identity information about the user. Part of the OpenID Connect specification.
access token
A token that can be provided as part of an HTTP request that grants access to the service being invoked on. This is part of the OpenID Connect and OAuth 2.0 specification.
direct grant
A way for a client to obtain an access token on behalf of a user via a REST invocation
protocol mappers
For each client you can tailor what claims and assertions are stored in the OIDC token or SAML assertion. You do this per client by creating and configuring protocol mappers
user federation provider
Keycloak can store and manage users. Often, companies already have LDAP or Active Directory services that store user and credential information. You can point Keycloak to validate credentials from those external stores and pull in identity information
identity provider
An identity provider (IDP) is a service that can authenticate a user. Keycloak is an IDP
identity provider federation
Keycloak can be configured to delegate authentication to one or more IDPs. Social login via Facebook or Google+ is an example of identity provider federation. You can also hook Keycloak to delegate authentication to any other Open ID Connect or SAML 2.0 IDP
Frequently, resource servers only perform authorization decisions based on role-based access control (RBAC), where the roles granted to the user trying to access protected resources are checked against the roles mapped to these same resources.
— https://www.keycloak.org/docs/latest/authorization_services/
Scope
A resource’s scope is a bounded extent of access that is possible to perform on a resource. In authorization policy terminology, a scope is one of the potentially many verbs that can logically apply to a resource.
— https://www.keycloak.org/docs/latest/authorization_services/
usually indicates what can be done with a given resource
— https://www.keycloak.org/docs/latest/authorization_services/
resource
— https://www.keycloak.org/docs/latest/authorization_services/
you can have a project resource and a cost scope, where the cost scope is used to define specific policies and permissions for users to access a project’s cost
— https://www.keycloak.org/docs/latest/authorization_services/
permission associates the object being protected with the policies that must be evaluated to determine whether access is granted.
X CAN DO Y ON RESOURCE Z
where …
X represents one or more users, roles, or groups, or a combination of them. You can also use claims and context here.
Y represents an action to be performed, for example, write, view, and so on.
Z represents a protected resource, for example, “/accounts”.
— https://www.keycloak.org/docs/latest/authorization_services/
After creating the resources you want to protect and the policies you want to use to protect these resources, you can start managing permissions.
— https://www.keycloak.org/docs/latest/authorization_services/
identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
Client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request
Important to note that access tokens are usually short lived and often expired after only minutes. The additional refresh token that was transmitted by the login protocol allows the application to obtain a new access token after it expires. This refresh protocol is important in the situation of a compromised system. If access tokens are short lived, the whole system is only vulnerable to a stolen token for the lifetime of the access token. Future refresh token requests will fail if an admin has revoked access. This makes things more secure and more scalable
Confidential clients are required to provide a client secret when they exchange the temporary codes for tokens
Public clients are not required to provide this client secret.
Public clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client
HTML5/JavaScript clients always have to be public clients because there is no way to transmit the client secret to them in a secure manner
The realm RSA public key is retrieved from the endpoint
[…]
Obtaining a certificate file for the realm public key (.pem format)
The x5c filed value is copied between —–BEGIN CERTIFICATE—–
—–END CERTIFICATE—– directives
— https://www.janua.fr/keycloak-access-token-verification-example/
signature is validated by copying teh PEM certificate obtained previously in the verify signature section (public key section)
— https://www.janua.fr/keycloak-access-token-verification-example/
Each client has several built-in mappers that are created for it by default. They map things like, for example, email address to a specific claim in the identity and access token.
You can opt to include or exclude the claim from both the id and access tokens by fiddling with the Add to ID token and Add to access token switches.
Keycloak can pre-generate configuration files that you can use to install a client adapter for in your application’s deployment environment
Client roles are basically a namespace dedicated to a client. Each client gets its own namespace
If the client has to explicitly request another client’s role, the role has to be prefixed with the client ID when performing a request using the scope parameter
For example, if the client ID is account and the role is admin, the scope parameter is:
`scope=account/admin`
In Keycloak, access tokens are digitally signed and can actually be re-used by the application to invoke on other remotely secured REST services
The Attributes and Role Mappings tab work exactly as the tabs with similar names under a user. Any attributes and role mappings you define will be inherited by the groups and users that are members of this group.
— https://wjw465150.gitbooks.io/keycloak-documentation/content/server_admin/topics/groups.html
In the IT world the concepts of Group and Role are often blurred and interchangeable. In Keycloak, Groups are just a collection of users that you can apply roles and attributes to in one place. Roles define a type of user and applications assign permission and access control to roles
Aren’t Composite Roles also similar to Groups? Logically they provide the same exact functionality, but the difference is conceptual. Composite roles should be used to apply the permission model to your set of services and applications. Groups should focus on collections of users and their roles in your organization. Use groups to manage users. Use composite roles to manage applications and services.
difference between a classic Refresh token and an Offline token is, that an offline token will never expire and is not subject of SSO Session Idle timeout
The offline token is valid even after a user logout or server restart
Keycloak will look into its own internal user store to find the user. If it can’t find it there it will iterate over every User Storage provider you have configured for the realm until it finds a match
The most important endpoint to understand is the well-known configuration endpoint. It lists endpoints and other configuration options relevant to the OpenID Connect implementation in Keycloak. The endpoint is:
realms/{realm-name}.well-known/openid-configuration
This refresh protocol is important in the situation of a compromised system. If access tokens are short lived, the whole system is only vulnerable to a stolen token for the lifetime of the access token. Future refresh token requests will fail if an admin has revoked access. This makes things more secure and more scalable.
Confidential clients are required to provide a client secret when they exchange the temporary codes for tokens
Public clients are not required to provide this client secret. Public clients are perfectly fine so long as HTTPS is strictly enforced and you are very strict about what redirect URIs are registered for the client
Certificate Endpoint /realms/{realm-name}/protocol/openid-connect/certs The certificate endpoint returns the public keys enabled by the realm, encoded as a JSON Web Key (JWK).
keycloak OpenID Connect endpoints
- /realms/{realm-name}/protocol/openid-connect/token
- This is the URL endpoint for obtaining a temporary code in the Authorization Code Flow or for obtaining tokens via the Implicit Flow, Direct Grants, or Client Grants.
- /realms/{realm-name}/protocol/openid-connect/auth
- This is the URL endpoint for the Authorization Code Flow to turn a temporary code into a token.
- /realms/{realm-name}/protocol/openid-connect/logout
- This is the URL endpoint for performing logouts.
- /realms/{realm-name}/protocol/openid-connect/userinfo
- This is the URL endpoint for the User Info service described in the OIDC specification
Notes pointant ici
- bitnami ne se configure pas bien
- develop an android application using keycloak and localhost redirection
- how do I create an OAuth 2.0/OIDC resource server? (blog)
- How do I use this in real life? (blog)
- how to discuss OIDC with keycloak
- how to structure/organize a multi technologies repo?
- integrate keycloak with hashicorp vault
- keycloak realm keys
- make sense of keycloak, openid connect, oauth 2.0, jwt, jws (blog)
- Securing Applications and Services Guide
- System for Cross-domain Identity Management
- trying authenticating to keycloak using google as Identity Provider