I'm developing a custom federation that communicates with my user
repository via webservices.
Probably this is a very strange scenario for a federation but that's the
unique way that I have to communicate with the repository.
My problem is that, as the webservices only exposes methods such as
createUser and updateUser, I'm having problems with registrations and user
profile updates because I'm not being able to do atomic calls to the
webservice methods, with all the information that I need.
As far as I know, from the properties file example and from the ldap
federation source (probably I'm missing something) it seems that the
federation api is intended to update and sync attribute by attribute
(Keycloak <-> Federation).
Am i wrong? Do you suggest another approach? Should I give up from having a
federation that uses a webservice?
In the JWT token there is a field 'aud', or audience, which function is to state for which client(s) that token is intended.
Currently (TokenManager:433) this is set to the client id:
This seems fine in general, but we would like to have a token with multiple entries in the audience field. This is possible and an array value is even claimed to be the 'general case': https://tools.ietf.org/html/rfc7519#section-4.1.3 (where one single value is the 'special case')
Background is that we have a Keycloak running for a login of a frontend that talks to multiple different resource servers. We'd prefer to use one token for all of those resource servers. The resource servers use Spring Security, which explicitly checks that the 'name' you give to your Spring service is matched by (a value of) the audience field of the JWT token. So now we have to give all resource servers the same 'name', which doesn't feel right.
So we need some way to influence the value of the audience field. This could be achieved by following this RFC: https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 which suggests to include a parameter to the request for the token. But that RFC does not consider multiple values for the audience. Another option would be to add an audience field in the settings of a Client in Keycloak. Which would, if set, define the audience field of the JWT token. This could be a comma separated string value that would translate to a JSON array. A question about this could be: 'then where to leave the client id?'. As suggested by this: https://stackoverflow.com/questions/32013835/client-id-or-multiple-audien... the best place to put the client id is in the 'azp' field (authorized party).
<https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00>Does the KeyCloak team see this as a valuable addition? Will it be implemented somewhere in the future? Or can we make a pull request ourselves that will be merged?
Currently the TOTP issuer is just set to the name of the realm. Since the issuer name is the heading of the entry that appears in the Google Authenticator app, we’d love to be able to customize the issuer name in the admin console. Would this be reasonable? Can I create a ticket?
We are using login restful service of 1.4.0 final version.
Sometimes the login takes quite some time(around 15 secs) to fetch the
token id given back by login service.
On subsequent call for login rest service takes very less time(75 milisecs)
This is a complete random behavior.
Kindly let me know how to overcome this issue.
below is the snap of Token timeouts.
[image: Inline image 1]
Have everyone tried the newest WildFly version yet?
I receive the following error:
Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
... 6 more
Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000380: Distributed Executors Framework is not supported in simple cache
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_51]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_51]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_51]
at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_51]
... 19 more
I guess the problem could be the new infinispan version (8.1.0).
This fails for me. Can't figure out why. It passes if I just go into
testsuite/integration and run mvn clean install, doesn't pass on a full
build. I get BindAddress failures in startup. Not sure how this test
is different than others other than it being the very last test that is run.
JBoss, a division of Red Hat
The last phase of client templates would be to allow defining
configuration items in the client template that the client inherits. I
was going to implement it as an either or. There will be a switch
"Inherit Template Configuration" If this is off, then config items are
taken from the client, otherwise they are taken from the template.
There would be no mix and match.
FYI, I"m not sure I'll be able to finish this prior to our deadline of
early January. There's still a lot of JIRAs to do beyond this.
This week though, I think I want to rework and simplify client creation
a bit more. Create client on the admin console would only require must
needed config attributes:
Choose Client Template if wanted
These would be the defaults:
* Access type: public (pretty much covers any use)
* enabled true
* Redirect URIs would default to Root/*
* Standard Flow true
* Direct Grants false
* Service Accounts false
Client Entity ID:
SAML SP Endpoint (not required, can make it more fine grained)
Choose client template if wanted
* Sign Docs: true
* Sign Assertions: false
* Client Signature Required: true
* Force POST BInding true
* Front Channel logout: true
* Force Name ID Format: false
* Name ID Format username
* Valid Redirect URIS renamed to Valid Assertion Consumer Service URIs
* certs would be generated by default
I'm also going to add a method to LoginProtocolFactory:
setupDefaults(ClientModel). When a client is created, this method would
be called, then the defaults would be overriden if they are set in the
ClientRepresentation. Right now, all this default logic is in the admin
console and I don't think it should be there.
JBoss, a division of Red Hat
I'm using the migration script to import my users with a new hash algorithm
with the following command -
However all my salt values get changed mid way during the whole operation
and are stored (in the database) differently than what they should be. I
checked the code and saw that the script expects the salt values to be
base64 encoded. I tried encoding the salt to base64, but the same issue
Lastly I tried to update the salt in the database (postgres) directly using
an UPDATE statement, which worked well. Another observation I made is that
salt is a 'bytea' data type in postgres and is stored as a hex value.
Is there some issue with the import script? I'll be happy to fix it if
anyone points me in the right direction.
*KUNAL KERKAR *| PRODUCT ENGINEER
Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
Web: www.plivo.com | Twitter: @plivo <http://twitter.com/plivo>, @tsudot
Free Incoming SMS for All US Short Codes – Get One Today!
I am working on integration keycloak authentication and setting up
authorization on endpoints in Dropwizard application.
I've looked into existing project here:
Also, I looked into
I am able to authenticate by username/password or passing keycloak token.
It is crucial for us to authenticate existing session without credentials
or keycloak token.
Does keycloak expose endpoints to authenticate via Cookie like:
KEYCLOAK_SESSION, KEYCLOAK_IDENTITY and/or KEYCLOAK_STATE_CHECKER
I'm not sure if this is the correct place for questions like these. Please
direct me otherwise.