[keycloak-user] FW: Architectural Blueprint/Recommendations

[Everson, David (MNIT)]

Good Afternoon,  If this is not the appropriate place to ask these types of questions, where does the community suggest that I seek these answers?  Thanks! Dave

-----Original Message-----
From: keycloak-user-bounces at lists.jboss.org <keycloak-user-bounces at lists.jboss.org> On Behalf Of Everson, David (MNIT)
Sent: Monday, June 18, 2018 9:41 AM
To: keycloak-user at lists.jboss.org
Subject: [keycloak-user] Architectural Blueprint/Recommendations

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>