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 Storage SPI
- Events SPI
- Themes
- Custom protocol mappers, broker mappers or LDAP mappers
Authentication SPI
- Allows to add your own authentication mechanism
- Flexibility to decide if particular authenticator is REQUIRED, ALTERNATIVE or OPTIONAL
- Example
UserStorage SPI
- Allows to plug your own source of users
- Implementation can decide which user's metadata are supported
- The non-supported data will be always stored in Keycloak DB
- For example: Just firstName, email, lastName and passwords are supported by my DB. Rest to be in Keycloak DB
- LDAP integration is done through UserStorage SPI
Authorization - intro
- OIDC and SAML2 doesn't handle authorization on app side directly
- 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 - new component
- Still a technology preview
- Feedback welcome
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)
- X can do Y on Z
- X i user identity
- Y is action (Scope)
- Z is resource
- Policy - the actual implementation of authorization rule, which can decide
- Permission - binding between Resource (and eventually Scope) and Policy
- Evaluation - more policies can be subject decision. Configurable whether all need to grant or just single one 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
Q & A
- Presentation: http://mposolda.github.io/presentations/keycloak-jbug2.html
- Example: https://github.com/mposolda/authz-blog-example
- Docs: http://www.keycloak.org