Keycloak - agile-solution

Understanding OIDC

Truly understand Keycloak as an OIDC IdP

OIDC providers and PKS and DEX

Dex is an identity service that uses OpenID Connect to drive authentication for other apps.

Dex acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.

Kong API gateway and Keycloak

A modern API gateway like Kong enables organizations to achieve some use cases much more easily than traditional gateways. The reason is older, traditional gateways try to provide as many features as possible into a heavyweight monolith, while modern solutions use a best-in-breed approach.

Envoy sidecar filters and Keycloak

Having API gateways like Kong together will become redundant once you run ISTO envoy and filters

Securing services

Istio is configured with Kubernetes Custom Resource Definition (CRD) objects. The two main objects for configuring Istio's security policies are the Policy and DestinationRule object. Policy objects are used to configure the security settings, a DestinationRule in Istio is used to configure how clients talk to a service. Istio provides 2 levels of security.

Transport authentication, also known as service-to-service authentication: mTLS (mutual) between services, Istio/Citadel taking care of key and certificate management and handles getting the certificates and keys onto the application instances. Using these certificates, Istio-enabled clusters have automatic mutual TLS. With Istio, communication between services in the mesh is secure and encrypted by default.
Origin authentication, also known as end-user authentication: When we use mTLS as described above, we can not only encrypt the connection, but more importantly know exactly who is calling whom. But what happens when service A is making a request to service B on behalf of user X? Typical way for services to communicate end-user or origin identity (the user logged in) is passing identity tokens like JSON Web Tokens. These tokens are given out to represent an authenticated user and the claims that user has. Each application language/framework historically had to rely on libraries to handle verifying and unpacking the JWT tokens. For example, for the popular Keycloak Identity and SSO project, there are language plugins for each popular language to handle some of this responsibility.

Note: For origin authentication (JWT), the application is responsible for acquiring and attaching the JWT credential to the request, see.

Read Istio security concepts

Install Keycloak Operator

Log on to katacoda

execute the following commands from these sources

Read the operator SDK user guide here

Checkout this example controller

git clone https://github.com/keycloak/keycloak-operator.git
cd keycloak-operator
kubectl apply -f deploy/crds/
kubectl create namespace keycloak
kubectl apply -f deploy/role.yaml -n keycloak
kubectl apply -f deploy/role_binding.yaml -n keycloak
kubectl apply -f deploy/service_account.yaml -n keycloak
kubectl apply -f deploy/operator.yaml -n keycloak
kubectl apply -f deploy/examples/keycloak/keycloak.yaml -n keycloak
kubectl apply -f deploy/examples/realm/realm_with_users.yaml -n keycloak
watch kubectl get all -n keycloak

Wait till everything is started up

kubectl logs -f keycloak-0 -n keycloak

kubectl exec -ti keycloak-0 -n keycloak /bin/bash

cd /opt/jboss/keycloak/standalone/configuration

Add Keycloak Metrics SPI endpoints for Prometheus

A Service Provider that adds a metrics endpoint to Keycloak. The endpoint returns metrics data ready to be scraped by Prometheus.

Two distinct providers are defined:

MetricsEventListener to record the internal Keycloak events
MetricsEndpoint to expose the data through a custom endpoint

Get it at github

Understanding the Oauth 2.0 Authorization Code Grant Type

The Authorization Code Grant Type is probably the most common of the OAuth 2.0 grant types that you’ll encounter. It is used by both web apps and native apps to get an access token after a user authorizes an app. In OAuth 2.0, the term “grant type” refers to the way an application gets an access token. OAuth 2.0 defines several grant types, including the authorization code flow. OAuth 2.0 extensions can also define new grant types.

Spring Cloud Security

Spring Cloud Security offers a set of primitives for building secure applications and services with minimum fuss. A declarative model which can be heavily configured externally (or centrally) lends itself to the implementation of large systems of co-operating, remote components, usually with a central indentity management service. It is also extremely easy to use in a service platform like Cloud Foundry. Building on Spring Boot and Spring Security OAuth2 we can quickly create systems that implement common patterns like single sign on, token relay and token exchange.

Springboot Oauth2 Token Relays

A Token Relay is where an OAuth2 consumer acts as a Client and forwards the incoming token to outgoing resource requests. The consumer can be a pure Client (like an SSO application) or a Resource Server.

Client Token Relays

If your app is a user facing OAuth2 client (i.e. has declared @EnableOAuth2Sso or @EnableOAuth2Client) then it has an OAuth2ClientContext in request scope from Spring Boot. You can create your own OAuth2RestTemplate from this context and an autowired OAuth2ProtectedResourceDetails, and then the context will always forward the access token downstream, also refreshing the access token automatically if it expires. (These are features of Spring Security and Spring Boot.

resource Server Token Relays

If your app has @EnableResourceServer you might want to relay the incoming token downstream to other services. If you use a RestTemplate to contact the downstream services then this is just a matter of how to create the template with the right context.

If your service uses UserInfoTokenServices to authenticate incoming tokens (i.e. it is using the security.oauth2.user-info-uri configuration), then you can simply create an OAuth2RestTemplate using an autowired OAuth2ClientContext (it will be populated by the authentication process before it hits the backend code). Equivalently (with Spring Boot 1.4), you could inject a UserInfoRestTemplateFactory and grab its OAuth2RestTemplate in your configuration. For example:

@Beanpublic OAuth2RestTemplate restTemplate(UserInfoRestTemplateFactory factory) {

return factory.getUserInfoRestTemplate();

}

Origin Authentication with Keycloak

I configured Keycloak on Active Directory by defining a keycloak user federation. End-user web client authenticating (Keycloak confidential client) over SPNEGO/Kerberos (1, 2, 3, 4 and 5) tickets and downstream REST API calls (Authorization) done over JWT tokens (6), so called Keycloak baerer-only clients.

Policy objects

To configure Istio to both use mTLS and verify the JWT token in a request (and fail the request if it doesn't exist, is invalid, or is expired), we can configure a Policy object. If a client productpage tries to connect to the reviews service, their request wouldn't make it to the service unless the JWT authentication succeeds. Another good thing about Istio's implementation here is that the request is also protected my mTLS.

DestinationRule objects

These DestinationRule objects will require clients use mTLS when making calls to services in the default namespace. We are also configuring the TLS mode to be ISTIO_MUTUAL which means we'll expect Istio to manage the certificates and keys as well as mount them into the services (using Kubernetes secrets in Kubernetes) so that the service proxy can use them to establish TLS.

Helm installing Keycloak server

This page is about installing, setting up and integrating Keycloak with MS Active Directory over LDAP.

git clone https://github.com/agilesolutions/charts-istio
cd charts-istio/charts
helm install keycloak/

Keycloak SpringBoot integration

Keycloak is an open source Identity and Access Management solution aimed at modern applications and services. It makes it easy to secure applications and services with little to no code.

Configure Keycloak

This example helped me a lot setting up Keycloak.

Create a Keycloak realm called istio.
Select that istio realm and Read this page how to configure a user federation to integrate your company AD over LDAP
Create a public client called productpage under realm istio
Create 2 baerer-only clients called reviews and details under realm istio
Keycloak is configured with default admin user admin and password admin

Testing JWT token on details service

Some examples how you can get the Autorization token from Keycloak by this Read

kubectl run -i --rm --restart=Never tokenizer --image=tutum/curl --command -- curl -X POST 'http://keycloak:8080/auth/realms/istio/protocol/openid-connect/token' -H "Content-Type: application/x-www-form-urlencoded" -d 'username={demo-user}&password={demo-user}&grant_type=password&client_id=cars-web' | jq .access_token
The above command will output Authorization token from Keycloak, store the value in an environment variable called $token
kubectl port-forward $(kubectl get pod -n default -l app=details -o jsonpath='{.items[0].metadata.name}') -n default 8080
curl -vvv -H "Authorization: Bearer $token" http://details:8080/list

Add Istio RBAC

Istio’s authorization feature - also known as Role-based Access Control (RBAC) - provides namespace-level, service-level, and method-level access control for services. To expressing role based access to your services you specify a ServiceRole and ServiceRoleBinding. ServiceRole defines a group of permissions to access services. ServiceRoleBinding grants a ServiceRole to particular subjects, such as a user, a group, or a service. Read more

Understanding Kerberos Delegation in Windows Active Directory

Delegation is managed by the S4U2proxy extension, a front-end (user facing) server can request a kerberos ticket on behalf of a user to access a subsequent back-end server, providing seamless access to data users are allowed to view or edit on that back-end.

There are 2 types of delegation, Ticket Forwarding (from kerberos to kerberos) and Protocol Transition (switching from another authentication mechanism like SAML to kerberos), explained later on.

Constrained delegation means restricting access to back-end resources that the frontend-end app is allowed to delegate to, this is done by listing back-end servers SPN's on the security principal (AD computer or service object) that runs the front-end app, explained later.

Ticket Forwarding (S4U2proxy)...

1. user authenticates to front-end app over kerberos providing a valid TGS service ticket, user's Ticket-Granting Ticket (TGT) is placed into the service ticket, allowing front-end app to authenticate on behalf of that user.
..

Protocol Transition (S4U2self)...

1. user authenticates against another security mechanism like like SAML.
2. ....

Enabling constrained delegation, how to.

enable S4U2Self
enable Protocol Transition
Constraining to dedicated SPN's only

Please note that you will need to be Domain Admin or have at least the “SeEnableDelegationPrivilege” enabled in order to grant delegation.

S4U2Self

This extension enables any server to ask for a TGS on itself for an arbitrary identity. This is done with a TGS_REQ operation where the pre-authentication data contains the desired client identity for the KDC to generate the right ticket. In a traditional TGS_REQ operation, the client identity should be the requestor, so the computer account used by the host itself.

An important note to understand what’s to come, when the TGS service on the domain controller handles the TGS_REQ, it will look at the requestor’s “userAccountControl” attribute and look for the “TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION” bit. The returned ticket will be forwardable only if this bit is set.

Read

The relevancy of Resource-based constrained delegation.

Starting from Windows 2012/Windows 8 it is possible to configure another type of delegation: “Resource Based Constrained Delegation”. In this scenario it is the target resource (downastream REST API resource server) which decides which computer can act on behalf another identity. A specific new attribute was added by MS: “msDS-AllowedToActOnBehalfOfOtherIdentity” where you put the computer(s) names and the ACL’s that the destination (REST API resource server) computer will trust.

Read

Instead of using an allow list of SPNs on the front-end app AD object, you allow the resource owner to control delegation.
When a backend service receives a request from our frontend server to grant access on behalf of another user, the AD Key Distribution Center (KDC) checks the security descriptor in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the security principal running the backend service, and if it matches the descriptor under which the frontend service runs, access is granted.

A note on: does this new more complicated scenario of RBCD add value or can this be considered overhead. I guess this is only profitable when you have a decentralized administration of frontend (user facing) services and backend services. In the bank all AD administration done centrally by the same team, I feel giving these people more flexibility with through powershell is only adding more complexity to the process. I don't think it is improving things from a security point of view, so what is the win?

Is it worth all the effort - YAGNI

Only advantage I see is that RBCD supports cross-realm access (spanning multiple security realm), read In general the SFU extensions are old and supported by Java since Java 8 but with windows 2012R2 Microsoft added support to cross-realm access. Previously the three roles (final user, frontend server and backend server) should be in the same realm/domain but a new concept, called resource-based constrained delegation, was incorporated to expanse SFU for multi-realm. But...The JDK never supported the new feature as stated in this JDK bug.

XXX custom library support for JBoss JEE and Springboot

The best post I found so far on this topic

Code example 1

Code example 2

On of the best examples so far

The protocol overview for S4USelf and Proxy

MS-SFU kerberos extensions and cross-realm support Important read!!!!!!