Error enabling 'Sync Registrations' for LDAP (FreeIPA) User Federation
by Rafael Soares
I'm testing Keycloak LDAP User Federation with FreeIPA iDM Server.
I'm using the same environment used by @mposolda [1] with the @adelton's
FreeIPA Docker container image [2].
The integration (KC and FreeIPA) worked fine except for the sync for new
users created on KC side (new registrations). When I enable the 'Sync
Registrations' on the 'freeipa-ldap' User Federation and then try to add a
new user using the KC Web Console I get the following error:
KC server.log in TRACE mode:
"
2016-06-11 22:33:37,568 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
realm by name cache hit: master
2016-06-11 22:33:37,568 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
by id cache hit: master
2016-06-11 22:33:37,569 DEBUG [org.keycloak.services] (default task-5)
token active - active: true, issued-at: 1,465,684,397, not-before: 0
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.UserCacheSession] (default task-5)
getuserById 6f358dd3-3c20-4a84-b0b5-b02c77747a5a
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.UserCacheSession] (default task-5)
returning new cache adapter
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by name cache hit: security-admin-console
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: security-admin-console
2016-06-11 22:33:37,569 DEBUG [org.keycloak.services] (default task-5)
authenticated admin access for: admin
2016-06-11 22:33:37,569 DEBUG [org.keycloak.services] (default task-5) No
origin returning
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
realm by name cache hit: freeipa
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
by id cache hit: freeipa
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
by id cache hit: master
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
by id cache hit: master
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
by id cache hit: master
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: freeipa-realm
2016-06-11 22:33:37,569 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
getClientRoles cache hit: freeipa-realm
2016-06-11 22:33:37,570 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
getClientRoles cache hit: freeipa-realm
2016-06-11 22:33:37,570 TRACE
[org.keycloak.models.cache.infinispan.UserCacheSession] (default task-5)
getUserByUsername: kc_user1
2016-06-11 22:33:37,570 TRACE
[org.keycloak.models.cache.infinispan.UserCacheSession] (default task-5)
query null
2016-06-11 22:33:37,571 TRACE
[org.keycloak.models.cache.infinispan.UserCacheSession] (default task-5)
model from delegate null
2016-06-11 22:33:37,571 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] (default
task-5) Using filter for LDAP search: (&(uid=kc_user1)(objectclass=person))
. Searching in DN: cn=users,cn=accounts,dc=example,dc=test
2016-06-11 22:33:37,575 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] (default
task-5) Using filter for LDAP search:
(&(mail=kc_user1(a)example.test)(objectclass=person))
. Searching in DN: cn=users,cn=accounts,dc=example,dc=test
2016-06-11 22:33:37,577 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
getRealmRoles cache hit: freeipa
2016-06-11 22:33:37,578 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
getClients cache hit: freeipa
2016-06-11 22:33:37,578 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: broker
2016-06-11 22:33:37,578 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: realm-management
2016-06-11 22:33:37,578 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: liferay-saml-idp
2016-06-11 22:33:37,578 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: security-admin-console
2016-06-11 22:33:37,578 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: kitchensink
2016-06-11 22:33:37,579 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: admin-cli
2016-06-11 22:33:37,579 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
client by id cache hit: account
2016-06-11 22:33:37,579 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
getClientRoles cache hit: account
2016-06-11 22:33:37,580 TRACE
[org.keycloak.models.cache.infinispan.RealmCacheSession] (default task-5)
getClientRoles cache hit: account
2016-06-11 22:33:37,581 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager] (default
task-5) Creating entry
[uid=kc_user1,cn=users,cn=accounts,dc=example,dc=test] with attributes: [
2016-06-11 22:33:37,583 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager] (default
task-5) objectclass = person
2016-06-11 22:33:37,583 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager] (default
task-5) givenname =
2016-06-11 22:33:37,583 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager] (default
task-5) sn =
2016-06-11 22:33:37,583 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager] (default
task-5) cn =
2016-06-11 22:33:37,583 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager] (default
task-5) ]
2016-06-11 22:33:37,607 ERROR [io.undertow.request] (default task-5)
UT005023: Exception handling request to /auth/admin/realms/freeipa/users:
org.jboss.resteasy.spi.UnhandledException:
org.keycloak.models.ModelException: Error creating subcontext
[uid=kc_user1,cn=users,cn=accounts,dc=example,dc=test]
at
org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
at
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
at
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168)
... 37 more
Caused by: javax.naming.directory.SchemaViolationException: [LDAP: error
code 65 - attribute "uid" not allowed
]; remaining name 'uid=kc_user1,cn=users,cn=accounts,dc=example,dc=test'
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3166)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3081)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2888)
at com.sun.jndi.ldap.LdapCtx.c_createSubcontext(LdapCtx.java:812)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:341)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:268)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:256)
at
javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:197)
at
javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:197)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.execute(LDAPOperationManager.java:434)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager$7.execute(LDAPOperationManager.java:431)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.execute(LDAPOperationManager.java:536)
at
org.keycloak.federation.ldap.idm.store.ldap.LDAPOperationManager.createSubContext(LDAPOperationManager.java:431)
... 57 more"
FreeIPA Server ldap srv log:
""
tail -f /data/var/log/dirsrv/slapd-EXAMPLE-TEST/errors
[11/Jun/2016:22:33:37 +0000] - Entry
"uid=kc_user1,cn=users,cn=accounts,dc=example,dc=test" -- attribute "uid"
not allowed
""
----
It appears FreeIPA LDAP server is refusing the attribute 'UID'
Interesting is that the FreeIPA 'user_add' API operation states the 'uid'
attributes is required:
I tried to add a new user manually using the FreeIPA CLI and it worked
fine. See the FreeIPA CLI output:
"
[root@ipa /]# ipa help user-add
Usage: ipa [global-options] user-add LOGIN [options]
Add a new user.
Options:
-h, --help show this help message and exit
--first=STR First name
--last=STR Last name
--cn=STR Full name
--displayname=STR Display name
--initials=STR Initials
--homedir=STR Home directory
--gecos=STR GECOS
--shell=STR Login shell
--principal=STR Kerberos principal
--principal-expiration=DATETIME
Kerberos principal expiration
--email=STR Email address
--password Prompt to set the user password
--random Generate a random user password
--uid=INT User ID Number (system will assign one if not
provided)
--gidnumber=INT Group ID Number
--street=STR Street address
--city=STR City
--state=STR State/Province
--postalcode=STR ZIP
--phone=STR Telephone Number
--mobile=STR Mobile Telephone Number
--pager=STR Pager Number
--fax=STR Fax Number
--orgunit=STR Org. Unit
--title=STR Job Title
--manager=STR Manager
--carlicense=STR Car License
--sshpubkey=STR SSH public key
--user-auth-type=['password', 'radius', 'otp']
Types of supported user authentication
--class=STR User category (semantics placed on this attribute
are
for local interpretation)
--radius=STR RADIUS proxy configuration
--radius-username=STR
RADIUS proxy username
--departmentnumber=STR
Department Number
--employeenumber=STR Employee Number
--employeetype=STR Employee Type
--preferredlanguage=STR
Preferred Language
--certificate=BYTES Base-64 encoded server certificate
--setattr=STR Set an attribute to a name/value pair. Format is
attr=value. For multi-valued attributes, the command
replaces the values already present.
--addattr=STR Add an attribute/value pair. Format is attr=value.
The
attribute must be part of the schema.
--noprivate Don't create user private group
--all Retrieve and print all attributes from the server.
Affects command output.
--raw Print entries as stored on the server. Only affects
output format.
[root@ipa /]# ipa user-add ipa_user3 --first 'IPA
3' --last 'User3' --email 'ipa_user3(a)example.test' --all --raw
----------------------
Added user "ipa_user3"
----------------------
dn:
uid=ipa_user3,cn=users,cn=accounts,dc=example,dc=test
uid: ipa_user3
givenname: IPA 3
sn: User3
cn: IPA 3 User3
initials: IU
homedirectory: /home/ipa_user3
gecos: IPA 3 User3
loginshell: /bin/sh
mail: ipa_user3(a)example.test
uidnumber: 753200006
gidnumber: 753200006
has_password: FALSE
has_keytab: FALSE
displayName: IPA 3 User3
ipaUniqueID: 65f3f702-3021-11e6-b62c-0242ac110001
krbPrincipalName: ipa_user3(a)EXAMPLE.TEST
memberof:
cn=ipausers,cn=groups,cn=accounts,dc=example,dc=test
mepManagedEntry:
cn=ipa_user3,cn=groups,cn=accounts,dc=example,dc=test
objectClass: ipaSshGroupOfPubKeys
objectClass: ipaobject
objectClass: mepOriginEntry
objectClass: person
objectClass: top
objectClass: ipasshuser
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: krbticketpolicyaux
objectClass: krbprincipalaux
objectClass: inetuser
objectClass: posixaccount
"
Can someone help me find what is wrong on KC side? Maybe the KC mappers
mechanism?
Thanks in advance.
[1] https://github.com/mposolda/keycloak-freeipa-docker
[2] https://hub.docker.com/r/adelton/freeipa-server/
--
___
Rafael T. C. Soares
7 years, 10 months
Send verify email message
by LEONARDO NUNES
Hi everyone,
How can I send an email verification with the email verification message?
I'm using /send-verify-email service to send email verification to users after I create their account from Rest API.
The problem is that the email sent goes with the message "executeActionsBodyHtml" not the "emailVerificationBodyHtml" as I would expect.
The message "executeActionsBodyHtml" is generic and can be used for password update also.
--
Leonardo Nunes
________________________________
Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o.
This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation
7 years, 10 months
clustering error
by Snehalata Nagaje
Hi All,
I have set up keycloak cluster.
But somehow it is not working giving error as
type=LOGIN_ERROR, realmId=TESTAUTH, clientId=null, userId=null, ipAddress=10.0.13.44, error=expired_code, restart_after_timeout=true
error=expired_code, restart_after_timeout=true
Thanks,
Snehalata
7 years, 10 months
Keycloak cluster question
by Snehalata Nagaje
Hi All,
I am setting up keycloak cluster.
As we are running the keycloak server in full-ha profile with domain mode, there is by default configuration for hornet queue cluster, do we need this for keycloak?
Can we remove it?
Thanks,
Snehalata
7 years, 10 months
Re: [keycloak-user] Keycloak OAuth High CPU usage
by Stian Thorgersen
Again, CPU load is expected to be high while having 20 threads send as many
requests as they can. It's the total throughput that matters here.
There are loads of tuning you can do, but you should be able to get decent
numbers without any tuning.
On 26 May 2016 at 07:09, Vaibhav Naldurgkar <
vaibhav_naldurgkar(a)persistent.com> wrote:
> I still wondering what odd configuration I am following on my RHEL VM
> which is not sustaining few user request when checked from the output of
> top command. Could you please suggest if there are any Java specific
> parameters needs to be tuned for performance improvement. If needed I will
> share my configuration files for reference.
>
>
>
> Below is the screenshot of top output during one of the load test.
>
>
>
>
>
>
>
>
>
> *Thanks, Vaibhav*
>
>
>
>
>
>
>
>
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger@redhat.com]
> *Sent:* Wednesday, May 25, 2016 12:40 PM
> *To:* Vaibhav Naldurgkar
> *Cc:* Herzberg, Manuel; keycloak-user(a)lists.jboss.org
>
> *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage
>
>
>
> I did some tests with Linux VM when investigating how Keycloak scales. I
> had Keycloak running on a VM that was permitted 50% of a single core and
> had a throughput of 50 scenarios. Where a scenario includes a login
> request, a code to token request and a logout request. In our performance
> lab with a single node and a not particularly beefy machine we're seeing
> 150+ scenarios/second.
>
>
>
> On 24 May 2016 at 16:05, Vaibhav Naldurgkar <
> vaibhav_naldurgkar(a)persistent.com> wrote:
>
> Hello,
>
>
>
> What are the tests results on a Linux VM ? I just done same jmeter tests
> on AWS m4.xlarge instance; however far behind than the laptop tests results.
>
> @Stian – have you done tests using Linux VM ?
>
>
>
>
>
> Thanks, Vaibhav
>
>
>
> *From:* Herzberg, Manuel [mailto:manuel.herzberg@atos.net]
> *Sent:* Tuesday, May 24, 2016 5:52 PM
> *To:* stian(a)redhat.com; Vaibhav Naldurgkar
> *Cc:* keycloak-user(a)lists.jboss.org
> *Subject:* RE: [keycloak-user] Keycloak OAuth High CPU usage
>
>
>
> Hello,
>
> I am evaluating the Keycloak performance. Here my practical experience. My
> scenario is the same as Vaibhav’s:
>
>
>
> · Large amount of token have to be generated. This is done by
> requesting the Keycloak token REST endpoint via http. The different realms
> I am using have 1k 2k 3k and 4k keys for signing the tokens. (RSA) Longer
> keys result to longer runtime to generate these tokens.
>
>
>
> · I have more than 10k user each realm. Each request includes a
> new user.
> Requests look like this:
> host1:8080/auth/realms/demo-3072/protocol/openid-connect/token/
> with data:
>
> username=testuser1&password=password&client_id=customer-portal&grant_type=password
>
>
>
> · The response includes 3 tokens(access, refresh and id). In
> total more than 30 000 token have to be generated and signed.
>
>
>
> @Stian. You wrote you are able to invoke 10000 token refreshes in under 60
> seconds. A token refresh includes access, refresh and id token right? Can
> you explain us your scenario? How do you get such a high number?
>
> Some more results: just signing 3000 Token (800 Byte each) with a 2k key
> takes me 20 seconds (laptop i5-4310U, 12gb ram). I am doing this outside
> Keycloak with my own java program, but with the same implementation
> Keycloak is using. (sign() method in RSAProvider).
>
> The Keycloak implementation is signing tokens with RSA. HMAC and ECC are
> implemented as well as I saw in the code. Changing from RSA to HMAC or ECC
> is not possible in current release as i experienced. Are there plans to
> provide this in future? Defining this in a configuration file or via
> parameters would be nice.
>
> Best regards, Manuel Herzberg
>
>
>
>
>
> *From:* keycloak-user-bounces(a)lists.jboss.org [
> mailto:keycloak-user-bounces@lists.jboss.org
> <keycloak-user-bounces(a)lists.jboss.org>] *On Behalf Of *Stian Thorgersen
> *Sent:* Tuesday, May 24, 2016 8:31 AM
> *To:* Vaibhav Naldurgkar
> *Cc:* keycloak-user(a)lists.jboss.org
> *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage
>
>
>
>
>
>
>
> On 23 May 2016 at 10:02, Vaibhav Naldurgkar <
> vaibhav_naldurgkar(a)persistent.com> wrote:
>
> Yes, the direct access grant is ON for this client. I am trying to
> understand what you mean by “not planning on using web based flow?” Could
> you provide more clarification on this.
>
>
>
> If you are planning to do the web based flow (authorization code grant
> flow) you should test with that rather than direct grant. That being said
> the direct grant should still perform as well.
>
>
>
>
>
> This is what the scenario I am trying to execute and still have high CPU
> usages for KeyCloak Java process.
>
>
>
> · The end point URL
> /auth/realms/master/protocol/openid-connect/token has been called by Jmeter
> for 20 concurrent users per seconds to generate the tokens.
>
> · Even if used with crul command like “*curl -X POST -d
> "=admin&password=admin&password&client_id=HelloTest&grant_type=password"
> http://localhost:8080/auth/realms/master/protocol/openid-connect/token
> <http://localhost:8080/auth/realms/master/protocol/openid-connect/token>*”
> , in this case also the CPU utilizations goes around 100%.
>
> · After around 3 seconds of the test, in the output of top
> command on the KeyCloak server the CPU% for keycloak java process goes
> beyond 100%.
>
>
>
> Would it be possible for you to have a quick call for faster fix of this
> issue. This performance issue is holding to move KeyCloak to use as OAuth
> provider. If any other way is convenient for you please let me know for
> further discussion.
>
>
>
> Your JMeter test is using 20 concurrent threads to send as many requests
> to the direct grant api as it can. This will obviously cause Keycloak to
> consume a high percentage of the CPU. Especially if you are running
> everything on localhost as the network isn't going to be a bottleneck.
> Neither will the database as Keycloak caches everything in memory. The
> bottleneck will be the CPU.
>
>
>
> Authenticating users and obtaining a token requires password hashing as
> well as signing tokens, both are mainly CPU intensive. As you are using the
> direct grant api there's also less network traffic.
>
>
>
> You need to add some reports to your JMeter test so you can see how many
> requests Keycloak can handle. That way you can find out how many users can
> be authenticated per-second on your machine.
>
>
>
> If you only have 500 users remember they won't all login at the same time
> (seconds). Even if they all login at 9am sharp they will be spread out over
> 10 minutes or so, which would only be 1.2 logins/second.
>
>
>
>
>
> Thanks, Vaibhav
>
>
>
>
>
>
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger@redhat.com]
> *Sent:* Monday, May 23, 2016 12:01 PM
>
>
> *To:* Vaibhav Naldurgkar
> *Cc:* keycloak-user(a)lists.jboss.org
> *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage
>
>
>
> You are using direct grant to authenticate a user and obtain a token in
> the example above. This authenticates and creates a new session for each
> request. Are you not planning on using web based flow?
>
>
>
> What do you have password hashing intervals set to? Verifying password is
> CPU intensive, more than signing tokens.
>
>
>
> It shouldn't matter that user is stored in RedHat IdM as the user would be
> cached in Keycloak after first authentication, but it may be an idea to
> just double check by trying to authenticate to a user in Keycloak and not
> RH IdM.
>
>
>
> What results are you actually getting?
>
>
>
>
>
>
>
> On 20 May 2016 at 11:27, Vaibhav Naldurgkar <
> vaibhav_naldurgkar(a)persistent.com> wrote:
>
> Hi Stian,
>
>
>
> After reading your tests results of 10000 token refreshes in under 60
> seconds on your laptop, I am sure I am not following correct configuration
> and the documents are missing for reference.
>
>
>
> Could you please verify the below steps along with the screen-shots for
> the steps which I am following for the adding client and testing the Load
> performance using Jmeter. Please suggest if any changes are needed in the
> client configuration. In this case we are obtaining the token for user from
> KeyCloak.
>
>
>
> In my case the user have been stored on RedHat IdM which has been
> federated using KeyCloak.
>
>
>
>
>
> Step 1. Create new client called “LoadTest” , use the Client Protocol as
> “Openid-connect”.
>
> Used all defaults values post save of the client action.
>
>
>
> Step 2. Start the load tests using Jmeter and using the path as
> *“/auth/realms/master/protocol/openid-connect/token”* . Used 20 Number of
> Threads and used Post method.
>
>
>
>
>
> Below is the screen-shot for the step 1 related to Add Client.
>
>
>
>
>
>
>
>
>
> Below is the screen shot for the load test using Jmeter. In this case the
> Client ID was used as HelloTest.
>
>
>
>
>
>
>
> Http requests.
>
>
>
>
>
>
>
> Thanks, Vaibhav
>
>
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger@redhat.com]
> *Sent:* Friday, May 20, 2016 1:01 PM
>
>
> *To:* Vaibhav Naldurgkar
> *Cc:* keycloak-user(a)lists.jboss.org
> *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage
>
>
>
> Can you please elaborate a bit more on how your are testing scenario is?
> I'm a bit confused to what you are testing when you are talking about
> generating new tokens. Are you using OIDC or SAML? Are you talking about
> code->token exchanges, refresh token requests, or what?
>
>
>
> To test if your hardware is capable to deal with the load you need to test
> logins (verifying passwords are CPU intensive) as well as obtaining tokens
> (both code->token, done after login, and refreshing token, done ~1 min or
> so by active users, but most users won't continuously use the application).
>
>
>
> 500 users should be no problem at all. As an example with a single thread
> (which will use a single core) I could invoke 10000 token refreshes in
> under 60 seconds on my laptop. So a single core on my laptop should be able
> to handle 500 users.
>
>
>
> On 20 May 2016 at 08:00, Vaibhav Naldurgkar <
> vaibhav_naldurgkar(a)persistent.com> wrote:
>
> Hi Stian,
>
> Thank you for your reply.
>
>
>
> The new tokens needs to be generated for each user, which is needed from
> security point of view. The performance tests were also conducted using
> single Admin user and token for admin user; however in that case the
> performance was not good. In between 15th to 20th admin token access
> requests – the CPU usage of keycloak Java process was crossing 90 to 120%
> mark.
>
>
>
>
>
> As you have mentioned, Creating tokes are expected to be a bit CPU
> intensive – what should be the server configuration in terms of CPU to deal
> with more than 500 users to use keycloak as OAuth provider.
>
>
>
>
>
> Thanks, Vaibhav
>
>
>
>
>
>
>
> *From:* Stian Thorgersen [mailto:sthorger@redhat.com]
> *Sent:* Thursday, May 19, 2016 6:28 PM
> *To:* Vaibhav Naldurgkar
> *Cc:* keycloak-user(a)lists.jboss.org
> *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage
>
>
>
> Creating tokes are expected to be a bit CPU intensive as they need to be
> signed. When you say you try to generate tokens for 10-20 users are you
> doing performance tests and having 10-20 threads generating tokens? It
> shouldn't make any difference if you have 10 or if you have 200 users, it's
> the total number of tokens that can be generated that's an issue. Having
> 200 concurrent users with a access token timeout of 60 seconds should mean
> that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec.
>
>
>
> On 19 May 2016 at 13:24, Vaibhav Naldurgkar <
> vaibhav_naldurgkar(a)persistent.com> wrote:
>
> Hi All,
>
>
>
> I am using Keycloak 1.9.3 with default configuration. Keycloak server is
> installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version
> is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when
> we try and generate token(
> http:///auth/realms/master/protocol/openid-connect/token
> <http://auth/realms/master/protocol/openid-connect/token>) for more than
> 10-20 users the server gets too slow and cpu usage goes over 100%.
>
> Any pointers on how to improve performance of keycloak OAuth provider. We
> need to support at least 200 concurrent users.
>
>
>
>
>
> Thanks, Vaibhav
>
> DISCLAIMER ========== This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> DISCLAIMER ========== This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
>
>
>
> DISCLAIMER ========== This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
>
>
>
> DISCLAIMER ========== This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
>
>
>
> DISCLAIMER ========== This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
>
>
>
> DISCLAIMER ========== This e-mail may contain privileged and confidential
> information which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Persistent Systems Ltd. does not accept any liability for
> virus infected mails.
>
7 years, 10 months
New user, same e-mail
by Felipe Braun Azambuja
Hello all,
We have Keycloak connected to our Active Directory (read only),
everything working correctly, authenticating our employees. But there is
a case that is a little complicated.
When someone starts working here as a intern, the user has an employee
ID with four digits. If a person is a regular employee, it has five
digits. Windows login is made of the first 2 letters of the name, and
then the ID number, zero padded, as in *fe001173*. But there are times
that these interns are hired as employees, so the previous account is
*disabled* in AD and a new one is created.
The problem is that the e-mail address is the same. When this happens, I
can't even search the user in Keycloak admin interface, because it says
that it already has a user with the same e-mail. The old one is still
there, though; but if I go to its details, I can't change the e-mail
address, since it tries to sync it back to AD.
So far, the solution was changing it directly in the database and
restarting Keycloak, which is *not* a good thing to do.
Any thoughts on what we could do?
Thanks !
--
Felipe Braun Azambuja
DBA
Tecnologia da Informação e Comunicação
(48) 3281 9577
felipe.braun(a)intelbras.com.br
Esta mensagem, incluindo seus anexos, contém informações protegidas por lei, sujeitas a privilégios e/ou confidencialidades, não podendo ser retransmitida, arquivada, divulgada ou copiada sem autorização do remetente. O remetente utiliza o correio eletrônico no exercício do seu trabalho ou em razão dele, eximindo esta instituição de qualquer responsabilidade por utilização indevida. Caso tenha recebido esta mensagem por engano, por favor informe o remetente respondendo imediatamente a este e-mail, e em seguida apague-a do seu computador.
The information contained in this e-mail and its attachments are protected by law, subjected to privilege and/or confidentiality and cannot be retransmitted, filed, disclosed or copied without authorization from the sender. The sender uses the electronic mail in the exercise of his/her work or by virtue thereof, and the institution accepts no liability from its undue use. If you have received this message by mistake, please notify us immediately by returning the e-mail and deleting this message from your system.
7 years, 10 months
Fwd: Multi-org salesforce with single realm keycloak
by Anthony Fryer
Why do you say "very hard to get App1 to support multiple realms (no
adapter or keycloak support)"?
Keycloak does provide multi-tenancy support via the
KeycloakConfigResolver. See
https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant.
The issue would be if your app can't use a keycloak adapter.
On Thu, Jun 9, 2016 at 10:05 AM, Jesse Chahal <jessec(a)stytch.com> wrote:
> Hi,
>
> I'm back again. I'm trying to figure out how scale Identity Providers.
> We are planning on trying to integrate our App1 with salesforce. A
> user who logs into salesforce should be able to have a native feel of
> our App1 within it. Todo this we'll probably have to end up building
> salesforce native apps. For every salesforce organization/licensee we
> will have to register an Identity provider with keycloak to make sure
> they can correctly use App1. Some configuration options we came up
> with are listed below. Has anyone else solved a similar problem?
>
> OPTION 1
> ########################################################
> # Keycloak
> #
> # ---> master realm
> #
> # ---> realm 1
> #
> # --- ---> app1_client (open ID)
> #
> # --- ---> salesforce_org1_saml2.0_identity_provider
> #
> # --- ---> salesforce_org2_saml2.0_identity_provider
> #
> #
> #
> # Salesforce
> #
> # ---> org1
> #
> # ---- ----> salesforce_appX (uses App1)
> #
> # ---> org 2
> #
> # ---- ----> salesforce_appX (uses App1)
> #
> # ---- ----> salesforce_appY (uses App1)
> #
> # .....
> #
> #
> #
> # App 1
> #
> # ---> OpenID to realm1 (using adapter)
> #
> ########################################################
> benefits
> - single login page
> - single realm
> cons
> - login page with infinite number of identity provider buttons present
>
>
> OPTION 2
> ########################################################
> # Keycloak
> #
> # ---> master realm
> #
> # ---> realm 1
> #
> # --- ---> app1_client (open ID)
> #
> # --- ---> salesforce_org1_saml2.0_identity_provider
> #
> # ---> realm 2
> #
> # --- ---> app1_client (open ID)
> #
> # --- ---> salesforce_org2_saml2.0_identity_provider
> #
> #
> #
> # Salesforce
> #
> # ---> org1
> #
> # ---- ----> salesforce_appX (uses App1)
> #
> # ---> org 2
> #
> # ---- ----> salesforce_appX (uses App1)
> #
> # ---- ----> salesforce_appY (uses App1)
> #
> # .....
> #
> #
> #
> # App 1
> #
> # ---> OpenID to realm1, realm2, realm#.... (using adapter)
> #
> ########################################################
> benefits
> - single salesforce button per login page
> - users are more isolated in single realm
> cons
> - very hard to get App1 to support multiple realms (no adapter or
> keycloak support)
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
7 years, 10 months
Re: [keycloak-user] How to apply updates to keycloak instances
by Stian Thorgersen
Adding list back..
I don't see much value in a solution that doesn't also consider changes
done directly through admin console and/or admin endpoints. A proper
solution would use something along the lines of Liquibase/Git to have all
changes versioned and applied serially. That way they can be reproduced
fully.
On 10 June 2016 at 21:03, Jesse Chahal <jessec(a)stytch.com> wrote:
> I've been thinking about this problem for awhile and so far the
> solutions that I come up with all require that keycloak keeps tracks
> of changes in a database table (exactly how it works for liquibase).
> The GUI has a partial import feature. I haven't used it too
> extensively but I believe it probably does some sort of JSONtoPOJO
> serialization in order to figure out what the partial update it needs
> to be doing. Maybe we could add unique id identifiers to the
> existing/exported JSON files and have keycloaks import features
> determine whether the JSON file had already been applied or not. If
> there is a rest api for this as well then building an external cli or
> GUI tool would be much more feasible. Scott's solution requires either
> the external app to know the state of keycloak or keycloak's state to
> be blank. Its the best that could have been done with keycloak as it
> is now. Anyone have any comments regarding this possible solution?
>
> On Thu, May 26, 2016 at 11:19 PM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
> > Can you give me some examples of issues around Dockerized deployments and
> > services that are located at runtime (do you mean services that are
> > provisioned at runtime?)?
> >
> > On 26 May 2016 at 19:47, Scott Rossillo <srossillo(a)smartling.com> wrote:
> >>
> >> Stian, that’s fair, it does solve the OP's CI/CD problem when moving in
> >> the dev -> stage -> prod direction.
> >>
> >> Scott Rossillo
> >> Smartling | Senior Software Engineer
> >> srossillo(a)smartling.com
> >>
> >> On May 26, 2016, at 1:41 PM, Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
> >>
> >>
> >>
> >> On 26 May 2016 at 19:11, Scott Rossillo <srossillo(a)smartling.com>
> wrote:
> >>>
> >>> I guess it’s a matter of requirements, but with micro service
> >>> architectures there’s usually some sort of discovery mechanism
> required to
> >>> locale services at runtime. Netflix offers Eureka and then there’s
> etcd from
> >>> CoreOS that’s being used by Kubernetes. My point is that even if
> Keycloak
> >>> devs build some sort of way of picking up changes from the filesystem
> on
> >>> startup, that doesn’t solve all use cases.
> >>
> >>
> >> The problem is continuous integration right, and pushing changes from a
> >> test environment into production? So you need a reliable way to apply
> >> changes to both environments.
> >>
> >>>
> >>>
> >>> It doesn’t solve issues with Dockerized deployments and it doesn’t
> solve
> >>> the issue where services have to be located at runtime
> >>
> >>
> >> What are the issues it doesn't solve?
> >>
> >>>
> >>>
> >>> Scott Rossillo
> >>> Smartling | Senior Software Engineer
> >>> srossillo(a)smartling.com
> >>>
> >>> On May 26, 2016, at 2:27 AM, Stian Thorgersen <sthorger(a)redhat.com>
> >>> wrote:
> >>>
> >>>
> >>>
> >>> On 26 May 2016 at 02:15, Jesse Chahal <jessec(a)stytch.com> wrote:
> >>>>
> >>>> @Stian
> >>>> The approach described sounds similar to liquibase to me but with json
> >>>> and specific to keycloak. I feel like a lot of possible bugs could
> >>>> arise from this approach or at least quite a few feature requests.
> >>>> Would each json file only contain a single change? Would order matter
> >>>> in how they get applied if you put a bunch of json files in this
> >>>> directory at once? Can the same file be applied multiple times? These
> >>>> are the kind of issues I would expect to come up with this type of
> >>>> change management system. When I mentioned write our own tool/script
> >>>> to do it I was kind of thinking of a writing a liquibase like system
> >>>> that calls keycloak's rest api.
> >>>
> >>>
> >>> We haven't figured out all the details, but what you are proposing
> sounds
> >>> better. A single document that lists all changes, that can also import
> other
> >>> files, sorts out the ordering and we could add same type of ids as
> Liquibase
> >>> does to changesets.
> >>>
> >>> You could write it to use the rest api, then use a separate db to store
> >>> what changes have been applied, but would be better if Keycloak deals
> with
> >>> loading the changes directly as it can write to the db what changes
> have
> >>> been applied.
> >>>
> >>> One big issue is what happens if manual changes are done through the
> >>> admin console. One though (although probably very tricky to get right)
> is
> >>> that changes done through the admin console is added to the changeset.
> >>>
> >>>>
> >>>>
> >>>> @ Scott
> >>>> If I would compare the solution you mentioned to one of the options I
> >>>> listed in my original question "I've also considered writing my own
> >>>> updater tool using a scripting language (python/ruby) that calls
> >>>> keycloak's rest api." The worrying thing to me is that there is
> >>>> another piece of code that needs to maintained by our company and
> >>>> requires quite a bit of knowledge of keycloak's rest api. There would
> >>>> probably need to be some serious thought put into the architecture of
> >>>> the tool as well. Without a doubt it does provide the most control. We
> >>>> also live by a different methodology in regards to updating production
> >>>> clusters. From our perspective it is more of an issue to update
> >>>> manually as it becomes much easier to miss a step or in someway screw
> >>>> up if steps are performed manually. I'm not sure what the security
> >>>> implications would be from it occurring automatically, especially if
> >>>> during each step there is thorough testing (including from a security
> >>>> team). For our CI/CD pipeline our goal is to have it so every commit
> >>>> can automagically end up on production without human intervention.
> >>>>
> >>>> Currently we use a combination of an initial realm file to be included
> >>>> on startup and also use jq to modify the keycloak-server.json for new
> >>>> keycloak clusters. We don't need to generate realm or client keys as
> >>>> it is included in the initial realm file. That doesn't work for
> >>>> existing systems backed by a database that cannot be thrown away. That
> >>>> kind of leave me with the original option (and hardest) of "write a
> >>>> proprietary liquibase like system built ontop of keycloaks rest api".
> >>>> This is a hard problem to solve
> >>>
> >>>
> >>> Why proprietary? If we can agree on a design we'll happily accept a
> >>> contribution and maintain it as well.
> >>>
> >>>>
> >>>>
> >>>> On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer <
> anthony.fryer(a)gmail.com>
> >>>> wrote:
> >>>> > Thanks, I'll check it out.
> >>>> >
> >>>> >
> >>>> > On 05:38, Tue, 24/05/2016 Scott Rossillo <srossillo(a)smartling.com>
> >>>> > wrote:
> >>>> >>
> >>>> >> We use Jose4J[0] to create the keys and then jq[1] to modify the
> >>>> >> realm
> >>>> >> file.
> >>>> >>
> >>>> >> See the first line of code here for a super simple example of how
> to
> >>>> >> generate realm keys:
> >>>> >> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples
> >>>> >>
> >>>> >> PS - this may be doable with Keycloak but Jose4J is very
> lightweight
> >>>> >> for
> >>>> >> writing a simple script on a CI server.
> >>>> >>
> >>>> >> [0]: https://bitbucket.org/b_c/jose4j
> >>>> >> [1]: https://stedolan.github.io/jq/
> >>>> >>
> >>>> >>
> >>>> >> Scott Rossillo
> >>>> >> Smartling | Senior Software Engineer
> >>>> >> srossillo(a)smartling.com
> >>>> >>
> >>>> >> On May 21, 2016, at 10:20 PM, Anthony Fryer <
> anthony.fryer(a)gmail.com>
> >>>> >> wrote:
> >>>> >>
> >>>> >> Hi Scott,
> >>>> >>
> >>>> >> How do you generate the realm keys when creating the new keycloak
> dev
> >>>> >> instances? Do you use a keycloak api or some other way? I'm
> >>>> >> interested in
> >>>> >> having a standard realm template that is used to create new realms
> >>>> >> but would
> >>>> >> need to change the realm keys when importing this template into
> >>>> >> keycloak.
> >>>> >>
> >>>> >> Cheers,
> >>>> >>
> >>>> >> Anthony
> >>>> >>
> >>>> >> On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo
> >>>> >> <srossillo(a)smartling.com>
> >>>> >> wrote:
> >>>> >>>
> >>>> >>> We’re using Keycloak on production, stage/QA, development
> >>>> >>> environments
> >>>> >>> and every developer’s workstation / laptop.
> >>>> >>>
> >>>> >>> While there will always be differing options on how to
> successfully
> >>>> >>> do
> >>>> >>> change management, we’ve found a very effective method for
> handling
> >>>> >>> Keycloak
> >>>> >>> provisioning in all environments so that developers don’t need to
> >>>> >>> mess
> >>>> >>> around with. We’re a continuous integration / deployment shop
> using
> >>>> >>> micro
> >>>> >>> services and everything has to “just work” … I’ll give an overview
> >>>> >>> of our
> >>>> >>> process here but please keep in mind a few things:
> >>>> >>>
> >>>> >>> 1. This approach works for us, I’m not saying it’s the best way
> >>>> >>> 2. We do _not_ allow production config changes to be automated due
> >>>> >>> to
> >>>> >>> security implications
> >>>> >>> 3. We're very opinionated in our approach to configuration
> >>>> >>> management and
> >>>> >>> we don’t ever modify 3rd party software databases directly. We
> >>>> >>> always use
> >>>> >>> APIs.
> >>>> >>>
> >>>> >>> We deploy Keycloak to all environments using Docker images. On
> >>>> >>> developer
> >>>> >>> workstations we use Docker Compose to orchestrate bringing up all
> >>>> >>> services a
> >>>> >>> developer may need, including Keycloak.
> >>>> >>>
> >>>> >>> We have 4 docker images for Keycloak:
> >>>> >>> - Keycloak Base
> >>>> >>> \- Keycloak HA
> >>>> >>> \- Keycloak Dev
> >>>> >>> - Keycloak config manager*
> >>>> >>>
> >>>> >>> The base image includes all customizations necessary to bring up a
> >>>> >>> Keycloak instance configured with our modules and themes
> installed.
> >>>> >>> The HA instance builds off base and configures Keycloak to run as
> a
> >>>> >>> cluster node. This is used on stage and prod.
> >>>> >>> The dev instance builds off base and includes our realm file. On
> >>>> >>> startup,
> >>>> >>> this instance loads our realm configuration if it’s not already
> >>>> >>> loaded.
> >>>> >>>
> >>>> >>> All docker images are built and published by the CI server and
> >>>> >>> Keycloak
> >>>> >>> HA can be deployed to stage and prod after a clean CI build.
> >>>> >>>
> >>>> >>> Developers are free to add clients for testing, do whatever they
> >>>> >>> want,
> >>>> >>> etc. to their running dev instance. If they want to get back to
> our
> >>>> >>> stock
> >>>> >>> build, they pull the latest Docker image from our private Docker
> >>>> >>> repo and
> >>>> >>> restart it.
> >>>> >>>
> >>>> >>> Adding clients to stage and prod requires approval and is done by
> a
> >>>> >>> hand.
> >>>> >>> This is for security reasons. Once a configuration change is
> >>>> >>> detected on
> >>>> >>> stage - say a client is added - our CI server exports the realm
> from
> >>>> >>> stage,
> >>>> >>> changes the realm keys, and creates a new Keycloak Dev instance
> with
> >>>> >>> the
> >>>> >>> updated realm file.
> >>>> >>>
> >>>> >>> *A word about configuration management:
> >>>> >>>
> >>>> >>> Obviously, the realm file we generate knows the URLs of staging
> >>>> >>> services,
> >>>> >>> not local or development environment URLs. To overcome this we
> >>>> >>> introduced
> >>>> >>> another Docker based service called the Keycloak configuration
> >>>> >>> manger. It
> >>>> >>> runs on development environments and workstations. It’s
> responsible
> >>>> >>> for
> >>>> >>> discovering running services and updating Keycloak via its admin
> >>>> >>> endpoints
> >>>> >>> to reflect the proper configuration for the given environment.
> >>>> >>>
> >>>> >>> That’s it. The whole process is automated with the exception of
> >>>> >>> configuration changes to stage and prod which require a security
> >>>> >>> review.
> >>>> >>>
> >>>> >>> Hope this helps. Let me know if you’d like me to elaborate on
> >>>> >>> anything.
> >>>> >>>
> >>>> >>> Best,
> >>>> >>> Scott
> >>>> >>>
> >>>> >>> Scott Rossillo
> >>>> >>> Smartling | Senior Software Engineer
> >>>> >>> srossillo(a)smartling.com
> >>>> >>>
> >>>> >>> On May 20, 2016, at 1:46 AM, Stian Thorgersen <
> sthorger(a)redhat.com>
> >>>> >>> wrote:
> >>>> >>>
> >>>> >>> Firstly, just wanted to highlight that core Keycloak team are
> devs,
> >>>> >>> not
> >>>> >>> sysadmins/ops guys, so we have limited experience in continuous
> >>>> >>> delivery and
> >>>> >>> maintenance of real production systems. Hence, we'd love input
> from
> >>>> >>> the
> >>>> >>> community on this.
> >>>> >>>
> >>>> >>> As it stands we don't really have a proper solution. I believe the
> >>>> >>> best
> >>>> >>> you can do at the moment is either using import feature, partial
> >>>> >>> import or
> >>>> >>> admin rest endpoints. Import is not going to work IMO as it
> requires
> >>>> >>> re-creating the whole realm. Partial import may work, but would
> work
> >>>> >>> best
> >>>> >>> for new resources rather than modifying existing resources as it
> >>>> >>> does a
> >>>> >>> delete/create operation rather than attempt to modify. With the
> >>>> >>> admin rest
> >>>> >>> endpoints you'd get the best control of what's going on, but
> >>>> >>> obviously that
> >>>> >>> leaves a fair amount of the work.
> >>>> >>>
> >>>> >>> In the future we have an idea of introducing an "import directory"
> >>>> >>> it
> >>>> >>> would be possible to drop json files in here that would add,
> modify
> >>>> >>> or
> >>>> >>> delete resources (realms, clients, roles, users, whatever). This
> >>>> >>> would allow
> >>>> >>> dropping json files before the server starts and the server would
> >>>> >>> then
> >>>> >>> import on startup. It would also be possible to do this at runtime
> >>>> >>> and new
> >>>> >>> files would be detected at runtime. Finally, we also had an idea
> of
> >>>> >>> an
> >>>> >>> offline mode to run import of this (it would basically start the
> >>>> >>> server
> >>>> >>> without http listener, import files, then stop, so it could be
> used
> >>>> >>> in a
> >>>> >>> script/tool). Import is probably not the best name for it, as it
> >>>> >>> would
> >>>> >>> support modify and delete as well as "importing" new things.
> >>>> >>>
> >>>> >>> On 19 May 2016 at 19:53, Jesse Chahal <jessec(a)stytch.com> wrote:
> >>>> >>>>
> >>>> >>>> Following some of the best practices for continuous Integration
> and
> >>>> >>>> continuous delivery there needs to be environments for build,
> test,
> >>>> >>>> and production. This would mean that following these practices
> >>>> >>>> would
> >>>> >>>> require you to have multiple versions of keycloak at different
> >>>> >>>> stages
> >>>> >>>> of development cycle. Some of these environments might not have
> >>>> >>>> important persistent data while others might. In order to have
> >>>> >>>> builds
> >>>> >>>> transition from one environment to another there may be
> >>>> >>>> configuration
> >>>> >>>> changes required for a build to be valid. This is especially true
> >>>> >>>> when
> >>>> >>>> new services (openid clients) are being added or "default"
> >>>> >>>> accounts.
> >>>> >>>> I'm trying to come up with a scripted way of updating keycloak
> >>>> >>>> instances that are backed up by an RDMS. This may include adding
> >>>> >>>> new
> >>>> >>>> clients, adding new users, updating realm config, etc...
> Originally
> >>>> >>>> I
> >>>> >>>> was planning on simply exporting the realm config and importing
> it
> >>>> >>>> every time keycloak starts. If I enabled the OVERWRITE option I
> >>>> >>>> might
> >>>> >>>> overwrite things that I do not want overridden. This is
> especially
> >>>> >>>> true if there is some config that differ's based on whether it
> is a
> >>>> >>>> build, test, or production instance. If I don't enable it then it
> >>>> >>>> is
> >>>> >>>> only useful for new/blank keycloak environments. I considered
> using
> >>>> >>>> liquibase but since I do not have control of schema changes
> created
> >>>> >>>> by
> >>>> >>>> the keycloak team I might run into issues with my liquibase file
> >>>> >>>> not
> >>>> >>>> being valid after a migration/liquibase update by the keycloak
> team
> >>>> >>>> as
> >>>> >>>> my liquibase file would run after keycloak's does. There might
> also
> >>>> >>>> be
> >>>> >>>> some other unknown issues our liquibase changes conflicting
> somehow
> >>>> >>>> with keycloak's liquibase changes. I've also considered writing
> my
> >>>> >>>> own
> >>>> >>>> updater tool using a scripting language (python/ruby) that calls
> >>>> >>>> keycloak's rest api. The issues with this mechanism is it feels
> >>>> >>>> like I
> >>>> >>>> am recreating the wheel as well as not being able to find good
> >>>> >>>> documentation on keycloak's openid endpoints/url's used for
> >>>> >>>> different
> >>>> >>>> oauth2 flows. Even if I did find this documentation it would also
> >>>> >>>> require me to find a good openid client for the scripting
> language.
> >>>> >>>> This doesn't matter for our normal clients as they simply use the
> >>>> >>>> keycloak subsystems and adapters instead. I've also looked at
> >>>> >>>> commonly
> >>>> >>>> used server configuration software such as chef, puppet, and
> >>>> >>>> ansible.
> >>>> >>>> I don't see a good solution using any of those tools yet either.
> >>>> >>>> What
> >>>> >>>> have other people done for cases like this? Please don't tell me
> >>>> >>>> there
> >>>> >>>> is someone who is doing this all manually because that doesn't
> work
> >>>> >>>> in
> >>>> >>>> modern software development.
> >>>> >>>>
> >>>> >>>> - doesn't accidentally delete users
> >>>> >>>> - doesn't accidentally delete clients
> >>>> >>>> - doesn't invalidate sessions (optional)
> >>>> >>>> - works to bring up new, correctly configured, keycloak instances
> >>>> >>>> - handles applying updates to existing keycloak instances
> >>>> >>>> - can handle minor differences between keycloak instances (build,
> >>>> >>>> test, production) when updating
> >>>> >>>> - preferably can work well in rolling deployment scenario's.
> >>>> >>>> -- I hope the keycloak team is taking these into consideration
> when
> >>>> >>>> doing database migration between 1-2 releases. It would be nice
> if
> >>>> >>>> they set some specific rules for rolling updates between versions
> >>>> >>>> (aka
> >>>> >>>> backwards breaking changes)
> >>>> >>>> _______________________________________________
> >>>> >>>> keycloak-user mailing list
> >>>> >>>> keycloak-user(a)lists.jboss.org
> >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>> >>>
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> keycloak-user mailing list
> >>>> >>> keycloak-user(a)lists.jboss.org
> >>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>> _______________________________________________
> >>>> >>> keycloak-user mailing list
> >>>> >>> keycloak-user(a)lists.jboss.org
> >>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >
> >>>
> >>>
> >>>
> >>
> >>
> >
>
7 years, 10 months
