Scope Param with Keycloak
by Tomas Cerny
Hi all,
I am trying to use the scope param with keycloak, which is part of the open
id
http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
Here is an sample URL (from
https://openid.net/specs/openid-connect-basic-1_0.html#AuthenticationRequest
)
Which is
https://server.example.com/authorize?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
note the state param there
with keycloak this is my auth URL:
http://127.0.0.1:8080/auth/realms/example/protocol/openid-connect/auth?cl...
When I pass scope param, then it is ignored.
Does keycloak support scope param? Can I intercept it to make a custom
handler? (e.g. lookup DB data)
Sample Use Case: Keycloak has my custom UserFederation provides where I
issue user lookup to my SQL DB, and determine access, next basing on the
scope I like to post back to the app roles relevant to the scope param.
I know keycloak has static roles, but I need it contextual, such as - user
is master in scope = A, but reader in scope = B. Since the range of scopes
is dynamic and large, the use of client-ids is not sufficient.
I assume the scope can help me solving situation such as am I owned of an
object?
I did days of debugging keycloak code and cannot find much even thought
there is OAuth2Constants.Scope but may be that is something different?
and I seem some dead sample here: FishEye: changeset
d309fab8251d95f50f94c77e4d08e6e8c2977994
<https://source.jboss.org/changelog/Keycloak?cs=d309fab8251d95f50f94c77e4d...>
The alternative OpenAM supports scope param it - OpenAM Project - About
OpenAM <http://openam.forgerock.org/>
Thanks, Tom
Here a forum public users.
https://developer.jboss.org/message/934762#934762
9 years
Custom federation - webservice
by Jorge M.
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?
Thank you.
9 years, 9 months
Control over audience parameter in JWT token
by Erik Mulder
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:
token.audience(client.getClientId());
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?
Thanks, Erik
9 years, 9 months
Allow TOTP issuer name to be set in the admin console?
by Cory Snyder
Hey guys,
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?
Thanks,
Cory Snyder
9 years, 9 months
Login Rest Service Service Delay
by Satyajit Das
Hi Team,
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]
Regards,
Satya.
9 years, 9 months
WildFly 10.0.0.CR5 not working
by Michael Gerber
Hi all
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)
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162)
at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
... 6 more
Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000380: Distributed Executors Framework is not supported in simple cache
at org.infinispan.distexec.DefaultExecutorService.ensureFullCache(DefaultExecutorService.java:665)
at org.infinispan.distexec.DefaultExecutorService.<init>(DefaultExecutorService.java:181)
at org.infinispan.distexec.DefaultExecutorService.<init>(DefaultExecutorService.java:143)
at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.startLoading(InfinispanUserSessionInitializer.java:154)
at org.keycloak.models.sessions.infinispan.initializer.InfinispanUserSessionInitializer.loadPersistentSessions(InfinispanUserSessionInitializer.java:78)
at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$3.run(InfinispanUserSessionProviderFactory.java:111)
at org.keycloak.models.utils.KeycloakModelUtils.runJobInTransaction(KeycloakModelUtils.java:264)
at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory.loadPersistentSessions(InfinispanUserSessionProviderFactory.java:102)
at org.keycloak.models.sessions.infinispan.InfinispanUserSessionProviderFactory$2.onEvent(InfinispanUserSessionProviderFactory.java:86)
at org.keycloak.services.DefaultKeycloakSessionFactory.publish(DefaultKeycloakSessionFactory.java:47)
at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:84)
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]
at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
... 19 more
I guess the problem could be the new infinispan version (8.1.0).
Michael
9 years, 10 months
simplfying client creation
by Bill Burke
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:
OIDC:
Client ID
Root URL
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
SAML:
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9 years, 10 months
Issue with salt value while importing user json
by Kunal K
Hi,
I'm using the migration script to import my users with a new hash algorithm
with the following command -
bin/standalone.sh -Dkeycloak.migration.action=import
-Dkeycloak.migration.provider=dir -Dkeycloak.migration.dir=keycloak-data
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
persists.
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
<http://twitter.com/tsudot>
Free Incoming SMS for All US Short Codes – Get One Today!
<https://www.plivo.com/sms-short-code/?utm=emailsig>
9 years, 10 months
