Keycloak

Main features

• Authentication for web (and other) applications
• SSO
• Single-sign out
• Standards based (OpenID Connect, SAML2)

Identity management

• realms, clients, roles and users
• RDBMS or Mongo as underlying storage

UI

• Admin console
• Account management
• User login, registrations, reset passwords
• Fully pluggable (Themes support)

Identity providers

• Social brokering support (Facebook, Google, Twitter...)
• Any 3rd party identity provider brokering (OpenID Connect, SAML2, OAuth2)

• LDAP integration
• Kerberos support
• TOTP support

Adapters

• Both OpenID Connect and SAML2 based
• Wildfly 8-10
• EAP 6-7
• Tomcat
• Jetty
• JBoss Fuse / Karaf
• Javascript

Customizations

• Authentication SPI
• User Federation SPI
• Events SPI
• Custom protocol mappers, broker mappers or LDAP mappers

History and current state

• Started in early 2013 by Bill Burke and Stian Thorgersen
• 1.0.0.Final release in Summer 2014
• Latest version is 1.9.1
• 6 developers, 6 QA team members in Brno, Big community

Production support

• Product based on Keycloak planned to be released
• Product will be based on 1.9.x community branch
• Keycloak master branch opened for new features by community to KC 2.0
• KC engineers and QA are mainly focused on 1.9.x

• KC engineers and QA are mainly focused on 1.9.x
• Stabilization, bugfixing, performance (no new features)
• Community users, who wants product, encouraged to migrate to 1.9.X to catch bugs early
• Authorization planned for 2.X

Planned features for 2.0

• OpenID connect certification
• Better FreeIPA integration
• More plugability (extend Keycloak with your REST endpoints etc)
• Validations SPI
• Make some SPI more stable (especially User storage / federation)

• Authorization support
• Remove master realm, better authorization for admin console
• Whatever requested/needed by community and customers ;)

Direct access grants

• Based on "Resource owner password credentials grant" from OAuth2
• Client directly exchanges username and password of user for tokens
• Main usage in non-web clients
• Authentication flow support
• Possible to disable on client

Limitations

• Client needs to know credentials of user
• User can't have "required actions"
• Client can't require consents

Service accounts

• Alternative to direct access grants
• Based on "Client credentials grant" from OAuth2
• Client receives tokens on behalf of himself. No user credentials involved

Example

Custom claims

• SPI to allow change token (SAML assertion) anyhow you want
• Bunch of pre-defined implementations

Example

Identity providers

• Either use one of pre-defined social providers
• Or use any OpenID Connect, OAuth2 or Social provider
• Possibility to write your own
• Possibility to write your mapper
• First login flow

Example

Authorization - current state

• No special support
• OIDC and SAML2 doesn't handle authorization on app side directly
• So that keycloak ATM ;)
• Application has access token with roles and attributes and it needs to decide what to do
• Adapters has support for mapping of token roles into JEE roles

Authorization - future

• prototype by Pedro
• https://github.com/pedroigor/keycloak-authz
• Really just prototype under development
• ATM requires to build special branch of Keycloak (Pedro's fork) and then keycloak-authz

Possibilities

• Either part of Keycloak directly
• Pluggable extension deployable to Keycloak

Features

• Based on standards (OAuth2 , UMA, XACML planned)
• Flexible authorization rules (policies) decoupled from the application
• Possibility to support simple (role-based, user-based) to complex (Javascript rules, Drools rules etc)

• Policy Administration Point (PAP)
  • Administration of authorization rules/policies in Keycloak admin console
• Policy Decision Point (PDP)
  • Endpoint to send authorization request and receive tokens with authorization response
• Policy Enforcement point (PEP)
  • Support on application side to communicate with the PDP
  • In my understanding, something like "adapter" for authorization