anybody seeing master build failures?
by Bill Burke
Anybody else seeing this?
Tomcat 6 test is failing on my box. I pulled fresh copy of master and
removed org/keycloak from .m2. So I don't think its anything local on
my machine:
java.lang.NoSuchMethodError:
org.apache.tomcat.util.descriptor.DigesterFactory.newDigester(ZZLorg/apache/tomcat/util/digester/RuleSet;Z)Lorg/apache/tomcat/util/digester/Digester;
at org.apache.catalina.startup.ContextConfig.createWebXmlDigester(ContextConfig.java:527)
at org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1015)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:276)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
at org.apache.catalina.core.StandardContext.init(StandardContext.java:5703)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4453)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:822)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463)
at org.apache.catalina.startup.Embedded.start(Embedded.java:825)
at org.keycloak.testsuite.TomcatServer.start(TomcatServer.java:122)
at org.keycloak.testsuite.TomcatTest.initTomcat(TomcatTest.java:66)
--
Bill Burke
Red Hat
7 years, 3 months
@Column.updatable=false
by Bill Burke
This popped up in a support request, but we have a number of foreign
keys (with indexes) that are never changed, but yet are included in
update requests of those tables by Hibernate. It seems that a number
of databases (and Hibernate, although don't know if there is a setting
for that) will not check to see if the old value equals new value.
This can cause concurrency issues (db deadlock). I bet it is a big
performance issue too if indexes are updated as well.
Should this be bumped to a priority for 3.4.1? I'll create a JIRA if so.
--
Bill Burke
Red Hat
7 years, 3 months
Keycloak server automation
by Niels Bertram
Hi dev-team,
not sure if its of any value but wanted share with you a Jython based
automation suite to configure Wildfly and its various subsystems.
https://github.com/fareliner/jyboss-cli
The library also comes with an Ansible module that can be used to
re/configure a Keycloak server idempotent - the Ansible way.
https://github.com/fareliner/jyboss-cli/blob/master/module/jboss.py
Will publish a fully working Ansible playbook shortly, just wanted to see
if there is much interest in this kind of topic. I think it could be very
handy to give people a set of starter playbooks or even to use it for
creating more complex docker images of Keycloak using ansible-docker.
Let me know what you think.
Cheers,
Niels
7 years, 3 months
Role based Segregation of Duties in Keycloak
by Thomas Darimont
Hello,
for a use case I need to support segregation of duties across multiple
applications.
> Segregation of Duties (SoD) is a mechanisms that prevents accumulating of
too
> much power in the hands of a single person. It places a constraints on
assignments
> of entitlements to users. For example SoD may prevent a single user to
create a
> request and also approve it.
Have you already considered adding this feature?
In the context of Keycloak this would mean to specify that two roles are
mutually exclusive determined based on the overall effective roles of
a user - the same may to service accounts.
Issue is here:
https://issues.jboss.org/browse/KEYCLOAK-3307
Some thoughts about adding that to Keycloak.
Support for “Segregation of Duties” (SoD) for a realm could be controlled
with
an on/off switch.
If SoD is enabled an administrator can select a set of roles which are then
treated
as mutually exclusive to the given role when creating or updating a role.
Mutually exclusive roles could be stored as a pair of role1:role2 (with
their ids) in a table
like e.g. keycloak_roles_mutex or keycloak_roles_sod.
If role1 is mutually exclusive to role2 then role2 is mutually exclusive to
role1.
-
Creating / Updating a Role with SoD
When creating a new or editing an existing role (role1), an administrator
could configure SoD by specifying a list of roles that are mutually
exclusive
to the current role (e.g. role2) -> perhaps called “Segregation of Duty
Roles”
-
Validating a role assignment with SoD
When assigning a role to a user, keycloak would check if the given role
combined with any effective role of a user matches a registered pair in the
keycloak_roles_mutex table.
If this is the case the assignment would be rejected with an error, perhaps
indicating
which roles cause the conflict. Otherwise the role can be assigned.
Same would apply to roles added to groups when a user wants to join a group.
-
Special Case: Updating a Role with SoD
When configuring SoD for an existing role it might happen that there exists
already a
user role mapping with an then invalid configuration. In that case an SoD
cannot be
enabled for the given role until the conflicting role mappings are cleared.
Until Keycloak provides a way to inspect granted and effective roles
assigned to a user
in more detail users would need to fall back to database queries to find
all conflicting
user role mappings.
-
Removing a Role with SoD configuration
When a role is removed and it had SoD roles configured those mappings must
be removed as well.
Thoughts?
Cheers,
Thomas
7 years, 4 months
Proposal for merging user accounts in Keycloak
by Thomas Darimont
When integrating multiple legacy systems one often finds that a particular
user
has multiple user accounts. In such scenarios it would be helpful if users
could consolidate their user accounts themselves by merging some of them
into one.
Currently Keycloak doesn't have an official way to merge two existing user
accounts.
Since I'm currently facing this in a project I thought a bit about how this
could
be solved in Keycloak.
Keycloak could provide a dedicated "merge" sub-page in the account
application,
e.g. account/merge. There a authenticated user1 could select the account he
likes
to merge with and verify the ownership of this account.
If the ownership could be verified successfully the user1 would be asked
for a
final merge confirmation. If the user1 confirms the merge then the selected
user
account (user2) would be merged into the currently logged-in user account
(user1).
Some logic would then need to decide how to merge the selected user2 into
the
currently logged-in user1, e.g. by assining roles and / or consents and
potentially
copy over some user profile values.
The account for user2 would then either be marked as merged or deleted.
Login with
user2 is no longer possible from this point on.
This could be supported by a dedicated "user account merge" SPI that could
decide
whether two accounts can be merged, how the merge is performed and what
user information
will be merged. This would enable great flexibility and help quite a lot to
ease integration of legacy systems.
Finally after a successful merge a USER_ACCOUNT_MERGED event with some
metadata
(about user1, user2 etc.) would be fired to notify other systems about the
user account merger.
Here are the steps in some more detail:
# Authentication
0) Unauthenticated user1 goes to the /account/merge page and gets
redirected
to the login page.
1) User1 authenticates and gets redirected back to /account/merge
# Account Selection / Verification
2) User1 selects an account to merge with, e.g. user2 and verfies ownership
E.g. by showing an embedded login form and ask for Username + Password +
2nd Factor
if present
# Merge
3) Merge the user account
3.0) Ask user whether accounts should be merged (account of user1 will
become
the remaining / leading account). This is irreversible!
3.1) Avoid account modification for user2 during merge, e.g. deactivate the
old user (user2)
3.2) Record some information about the merged user
Perhaphs via user attributes or maintain an explicit list of merged users.
# Decide what should be merged
A built-in logic and / or the user decides what should be merged.
3.4) User Profile information (e.g. complete incomplete fields?
E.g. firstname, lastname, mobile, etc.)
3.5) Grant all roles of user2 to user1
3.6) Grant all consents of user2 to user1
3.7) Grant all group memberships of user2 to user1
Credentials of user2 would be ignored.
# Conclude the merge
4) Mark user2 as merged or delete user 2
Delete user2 or rename user2 and change email to be able to use that
information for user1.
4.1) Propagate user account merge as event
Propagate a USER_ACCOUNT_MERGED event via the EventListener infrastructure.
The event should contain at least the userId of user1, and the userId of
user2 and
tells which is now the leading account. This enables downstream systems to
get notified
about the account merge.
WDYT?
Cheers,
Thomas
7 years, 4 months
Questions about Standalone HA
by Tonnis Wildeboer
Hello,
I posted similar questions on keycloak-user, but it doesn't seem to be
the right audience. Please redirect me if these are not appropriate for
this group.
*Background:*
I am running Keycloak in a kubernetes cluster with a shared postgres
(RDS) db. Everything is hosted on AWS. The Keycloak instances are
deployed using Helm.
I have read the clustering and caching documentation and from that it
seems that the appropriate clustering mode in this scenario would be
"Standalone Clustered Mode". Therefore, I am using the
"jboss/keycloak-ha-postgres" Docker image. Since I am using the nginx
Ingress controller I have the prescribedPROXY_ADDRESS_FORWARDING=true
environment variable. Upon inspection of the Docker image, however, I
noticed that the $JBOSS_HOME/standalone/configuration/standalone-ha.xml
file in that image does not have the
proxy-address-forwarding="${env.PROXY_ADDRESS_FORWARDING}" attribute in
the <http-listener ...> element. I also noticed that the
jboss-dockerfiles/keycloak-server base image has a sed command to add
this to the standalone.xml file but not to the standalone-ha.xml file.
(Also, for the benefit of others interested in this configuration, I
have configured session affinity in the Ingress to avoid the default
round-robin routing, which causes infinite redirects to Keycloak,
bouncing between instances.)
Of the examples I have found via Google searches, I have not found
examples of deploying Keycloak this way, which is surprising. I have
seen examples with a single instance using the standalone postgres
image, but not standalone-ha ("Standalone Clustered").
*So here are my questions:*
1. Why doesn't the base jboss-dockerfiles/keycloak-server image also
modify the standalone-ha.xml file too, in the same way it modifies
the standalone.xml file:
(https://github.com/jboss-dockerfiles/keycloak/blob/0a54ccaccd5e27e75105b9...
2. I assume the discovery of the nodes between one another (for the
sake of the shared caches) is accomplished through multicast as long
as they are on the same subnet. Correct?
3. What should I be looking for in the logs to see whether the peer
node discovery is happening? What logging level do I need to see this?
4. If the nodes (pods) are in different AWS VPCs and there is no
explicit routing set up between them such that they cannot discover
one another, but they do share the same postgres instance, is there
any harm in this? I would assume that each node would take
responsibility for being the cache owner, and that is not a problem.
5. Is there any other documentation, etc that I should be looking at?
Thank you,
--Tonnis
7 years, 4 months
