9:40 a.m.
Hello,
Our organization has been using Keycloak over the last few years. During this time,
several versions and implementation approaches of Keycloak have popped up in the
organization as various organizational units leveraged Keycloak.
We are now at the point of taking Keycloak to the next level of maturity within the
organization with a common architecture and governance model around Keycloak/IDAM.
We have convened a working group to take our experiences to-date and formulate an
architecture which the organization can move forward with. The major point of contention
with the future architecture is the nature in which the instances and realms are
deployed.
To this end, I am looking for some feedback from the community regarding the most scalable
architectural blueprint/recommendation to help achieve the following requirements and
questions:
Here is a list of our assumptions/constraints:
1. The organization consists of 10 organizational units (i.e. realms).
2. Each organization unit supports 10-15 applications (i.e. clients) requiring
authentication/authorization.
3. The primary application profile is a web application. (i.e. keycloak access type of
'confidential')
4. The organization is starting to developing an increasing number of web services which
leverage bearer-only authn/authz.
5. For the organization, Keycloak would support 100,000 users.
6. Of the 100,000 users, 1-2% of those users would be federated via Active Directory.
7. Within an organization unit, users should be able to leverage SSO for any application
within the organizational unit.
8. The primary usage of applications are between core business hours.
9. The applications are accessible 24x7.
10. On any given day, about 20% of the total user base may log into at least one
application.
11. Due to inactivity requirements, users may typically have to re-authenticate multiple
times during the day.
12. The organization has a desire to maintain a common set of IDAM policies and reporting
(i.e. governance) across all organizational units.
13. The organization would provide a default template for all organizational units.
14. Each organization unit may modify/create their own template as business requirements
dictate.
15. Keycloak should be clustered for high availability.
16. Keycloak environment would be hosted on AWS, more than likely EC2 instances.
17. Client applications also hosted in AWS.
18. Keycloak's database would be PostgreSQL hosted in AWS RDS.
A few questions/concerns of the working group:
A. Is there any information available on the maximum size of an Keycloak installation?
Will Keycloak be scalable and performant given the above assumptions and constraints.
B. What's the best recommendation for distributing the Keycloak instances and realms.
Right now the group has three options on the table: 1) A single Keycloak install per
application (i.e. client); 2) A single Keycloak install per organizational unit (i.e.
realm); or 3) A single Keycloak install per organization (i.e. serving all realms and
clients).
C. A major concern the group has with a single Keycloak install (#3 in previous bullet) is
the high-availability in terms of performance and concerns of a rouge client affecting
other applications negatively. What is the community's recommendation for addressing
this concern?
D. Another major concern the group has with a single Keycloak install is the restarts that
are necessary when an organization unit deploys a new or updated template. The concern is
that all applications would be unavailable during the restart. We would be operating in
a clustered environment, is the best solution to this concern restarting individual
members of the cluster rather than the entire cluster?
E. For reporting and governance processes, the Keycloak API performs quite poorly when we
execute use cases such as "Report all Users of an Application". Given the
version we are currently on, to accomplish this we need to query all users in the realm
and then filter the users if they have the client/role combination. We understand that a
future release addresses this use case, but in the meantime the concern is such a query
will negatively affect all other clients using Keycloak. Any recommendations on handling
this use case prior to Keycloak 4.x?
F. Upgrading Versions of Keycloak. We have experienced some difficulty of upgrading
versions on server-side (we need to export, import vs a simple DB backup and deployment).
What is the recommendations for handling the upgrade of Keycloak from one version to the
next given the size of our user base?
I'm sorry for the long post, hopefully folks get to this point. Any insight that we
could receive would be greatly appreciated. We are at a critical cross-roads in our
Keycloak adoption and want to ensure we do this correctly.
Thanks!
Dave
Dave Everson
Application Development Team Lead | Environmental Health
Minnesota IT Services | Partners in Minnesota Department of Health
625 Robert Street North
St. Paul, MN 55155
O: 651-201-5146
Information Technology for Minnesota Government | mn.gov/mnit<http://mn.gov/mnit>
[Minnesota IT Services Logo]
[Facebook logo]<https://www.facebook.com/MN.ITServices>[LinkedIn
logo]<https://www.linkedin.com/company/mn-it-services>[Twitter
logo]<https://twitter.com/mnit_services>
