Different behavior in cluster with Grant Type Password and Id_token

By: Ivan Carrion user 16 Jun 2020 at 3:04 a.m. CDT

4 Responses
Ivan Carrion gravatar
##Expected behavior Response with id_token in both Gluu nodes ##Actual behavior Only one node is responding with id_token Yes, we know that Password as a Grant Type is an antipattern if we want to receive id_token in response (https://support.gluu.org/authentication/4831/id_token-not-returned-when-oxauthrestv1token-queried/), but we are getting it with one node. We've made test in balancer with 2 nodes: Sometimes receives, sometimes not. Then we leave only one node in balancer ("node 1"): Never receive id_token. Then we leave only the other one in balancer ("node 2"): Always return id_token. Our sync is up and works: ``` Suffix DN : Server : Entries : Replication enabled : DS ID : RS ID : RS Port (1) : M.C. (2) : A.O.M.C. (3) : Security (4) ----------:------------------:---------:---------------------:-------:-------:-------------:----------:--------------:------------- o=gluu : IP_A:4444 : 6588 : true : 12022 : 16130 : 8989 : 0 : : true o=gluu : IP_B:4444 : 6588 : true : 4752 : 15520 : 8989 : 0 : : true o=metric : IP_A:4444 : 8 : : : : : : : o=site : IP_A:4444 : 5903 : : : : : : : ``` In Gluu 3.1.2 always works. We have set all the configs we know up. Maybe in Gluu 3.1.2 this "feature" worked but in 4.0 has known issues by this antipattern (and is working on some nodes and not on the others). Please, help. Our development team says they can't "easily" change from Password to Implicit Grant Type and we want to upgrade our Gluu version. Thanks!
Gluu 4.0 CentOS 7.0
closed

Answers

By Ivan Carrion user 16 Jun 2020 at 4:54 a.m. CDT

Copy
Ivan Carrion gravatar
Update: I've checked oxauth.log and we see: ``` 2020-06-16 08:45:09,378 ERROR [qtp575335780-20] [org.gluu.oxauth.model.crypto.OxAuthCryptoProvider] (OxAuthCryptoProvider.java:229) - Failed to find private key by kid: ab595eee-ea19-4eb2-90fb-2159a019a469_sig_rs256, signatureAlgorithm: RS256(check whether web keys JSON in persistence corresponds to keystore file.) 2020-06-16 08:45:09,379 ERROR [qtp575335780-20] [org.gluu.oxauth.model.common.AuthorizationGrant] (AuthorizationGrant.java:266) - Failed to find private key by kid: ab595eee-ea19-4eb2-90fb-2159a019a469_sig_rs256, signatureAlgorithm: RS256(check whether web keys JSON in persistence corresponds to keystore file.) ``` I think that error is referenced here: https://github.com/GluuFederation/oxAuth/issues/1152 (but we installed the final 4.0 version) and here: https://support.gluu.org/identity-management/7787/the-link-in-the-document-doesnt-work/ As one of my clustered nodes works, I just copy oxauth-keys.jks from that to the failed one, I restarted the services and it seems it works now. My questions are: Have I been doing well copying that file? Maybe I'll have another issues in the future? May I update to version 4.1 to solve this issue? Thanks a lot!

By Mohib Zico staff 18 Jun 2020 at 4:53 p.m. CDT

Copy
Mohib Zico gravatar
>> My questions are: Have I been doing well copying that file? Maybe I'll have another issues in the future? May I update to version 4.1 to solve this issue? It should be copied over. How did you built this 4.0 cluster? By using standalone system or completely from scratch?

By Ivan Carrion user 19 Jun 2020 at 12:40 a.m. CDT

Copy
Ivan Carrion gravatar
From scratch... just following the Clustering guide in docs.

By Mohib Zico staff 19 Jun 2020 at 12:45 a.m. CDT

Copy
Mohib Zico gravatar
Thanks. For now, copying over the key is the key resolution for your problem what you have done already. But, I'll ask our QA team to perform a QA on this. All certs and keys should be synced by Cluster Manager. Thanks!

Post an answer