Getting Started with Open Source Identity Access Management (Keycloak) and Open Source Directory Service (389 Directory Server)

Hello everyone, welcome back to my writing space. Last time I met you all with my article about Single Board Computers and Cloudlet in LinkedIn. Then, I used to share feeds in my timeline about all the industry latest news.

This is my first post in medium. Those who got a chance to see my feeds in LinkedIn for the past 6 months could have noticed that most of my feeds talk about Kubernetes, API Gateways, O365, and IAM domains. In case of tools then, open-source tools, cloud-native tools, and especially numerous feeds about KeyCloak.

Today I’m going to take you all to the outset of establishing an Enterprise level Identity and Access Management (IAM) system and Directory Service using two prominent open-source tools with a quick hands-on lab.

Before starting our lab today, let see about IAM in a nutshell. Just for our convenience, let me break IAM with its sub functional or technical components, so that it will be simple to get the broader significance of IAM in much simpler terms. Access Management, Identity Management, and Identity Store or Directory Service.

Access Management — Controls the “Who has access to what” and grants access based on the individual relationship with the resources and services.

Identity Management — Manages the individual identity (from provisioning) and manage those identities access to resources and services.

Directory Service — Manage an identity as a user repository that stores identity data and attributes.

Every entity of an enterprise must have touchpoint/integration with the IAM solutions, from Infra, Databases, DevSecOps, Containers, API Security, SSO, Web / Mobile Application, MFA, and Cloud. I don’t mean the model of IAM deployment is whether traditional on-prem or cloud-based. These components of IAM are more are less similar in both deployments.

For larger organizations with an ingrained on-prem IAM solution, the intention of shifting IAM to the cloud sounds like an insurmountable task. On-prem IAM can federate with the cloud-based IAM of the same or any organizations. Most of the proprietary IAM solutions are expensive though it provides extended capabilities. In the open-source world, there are few prominent free/freemium solutions are available. My suggestions are Keycloak for Identity and Access management and 389 Directory Server for Directory Service. These are very robust, highly available and supported for various backend DB and OS.

And in today’s lab, I’m going to showcase the very basic capabilities of Access Management and Directory Server using Keycloak and 389DS.

• 389DS in Docker (Dev Mode) — Creating Datastore, Creating BaseDN, Creating a user, Creating a group, and assigning a user to the group.
• Keycloak in Docker (Dev Mode) — Creating user Federation between Keycloak and 389DS and creating a sample OIDC client application
• Testing — API based Login, JWT token, and API access using deployed solution

389DS in Docker (Dev Mode)

#Create volume and attach with contain to persist the configurations
docker volume create 389ds
#Docker Create
docker create --name 389ds -v 389ds:/data -p 3636:3636 389ds/dirsrv:latest
#Docker start
docker start 389ds
#Create Backend for the Directory Server
docker exec -i -t 389ds /usr/sbin/dsconf localhost backend create --suffix dc=389ds,dc=389ds.com --be-name userRoot
docker exec -i -t 389ds /bin/sh -c "echo -e '\nbasedn = dc=389ds,dc=389ds.com' >> /data/config/container.inf"
#Intialise the Server
docker exec -i -t 389ds /usr/sbin/dsidm localhost initialise
#Create User
docker exec -i -t 389ds /usr/sbin/dsidm localhost user create --uid deepak --cn deepak --displayName deepak --uidNumber 1000 --gidNumber 1000 --homeDirectory /home/deepak
$Update user mail
docker exec -i -t 389ds /usr/sbin/dsidm localhost user modify deepak "add:mail:deepaksks@yahoo.co.in"
#Create group
docker exec -i -t 389ds /usr/sbin/dsidm localhost group create --cn test_group
#Add the member to the newly created group
docker exec -i -t 389ds /usr/sbin/dsidm localhost group add_member test_group uid=deepak,ou=people,dc=389ds,dc=389ds.com
#Set password for the new user. Later it will be used to API Login in this demo
docker exec -i -t 389ds /usr/sbin/dsidm localhost account reset_password uid=deepak,ou=people,dc=389ds,dc=389ds.com
#Reset the BindDN/RootDN password. later it will ne used to make the federation between Keycloak and 389DS
docker exec -i -t 389ds /usr/sbin/dsconf -D "cn=Directory Manager" slapd-localhost directory_manager password_change

389DS is running in a container with port listening to 3636 and ldap port 3389.

Keycloak in Docker (Dev Mode)

#To Start Keycloak with https 
docker run --name keycloak -p 8443:8443 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak
#To Start Keycloak without https
docker run --name keycloak -p 80:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak
#Skip the below steps, if Keycloak started in https mode
#For any reason you want to access non-https instance from internet, run the below to change the default sslRequired=External to sslRequired=NONE
docker exec -i -t keycloak /bin/sh
cd /opt/jboss/keycloak/bin
#This will promt for password. password=admin
./kcadm.sh config credentials --server http://localhost:8080/auth --realm master --user admin
#Changing the setting
./kcadm.sh update realms/master -s sslRequired=NONE
#Restarting the service
./jboss-cli.sh --connect command=:reload

Just FYI, I have deployed these containers in my cloud VPC and now creating a docker network and connecting these containers with that network.

docker network create my-net
docker network connect my-net keycloak
docker network connect my-net 389ds

Keycloak is running in a container with the selected port

Move to Keycloak admin portal http://hostname:port/auth and login with the username and password (admin/admin)

Click User Federation from the left side panel and select LDAP from the dropdown

Change the values as shown in the screenshot (no need to change any values for the non-visible portion of this screenshot) and save the configurations and the sync the users.

Click User from the left side panel and then click View all users, now you can see the users Synced from 389DS. Click any user and you can see the various attributes for that user.

Let’s create a simple client application that can later use to test our Keycloak and 389DS federation.

Now Click Clients -> Create -> Client ID = test-client and Client Protocol = openid-connect and click save

Change the values as showing in the below screenshot (no need to change any values for non-visible portion of this screenshot) and save

The secret for this client will be available under the credential tab. Next to the settings tab.

Perfect, we have done with our setup and lets test with the user created in 389DS to access the Keycloak token API to get the JWT after user authentication and then call the user info API using the access token

Testing

Use postman to test the client application created in Keycloak, use the username and password same as given during 389DS user creation

Great, it’s working. Keycloak authenticated this federated user and returned the JWT token. The wrong password may give a response as below.

{
    "error": "invalid_grant",
    "error_description": "Invalid user credentials"
}

Now lets try to call the userinfo api using the Access Token

Add alt text

That’s it for today. I hope this will be somehow helpful for your references. Thank you so much for your patience to read a long article. kindly provide your feedback and suggestions.

Stay Safe from COVID-19