Error while logging in through the demo application
by Vivek Srivastav (vivsriva)
Hi,
I am getting error while logging into to access customer-list in the demo application. Is there a problem in my configuration, or is there a fix/workaround available.
Environment:
keycloak appliance 1.0-beta-3.
Settings:
Using the default datastore.
Configured the customer-app and product-app as per the instructions and deployed in the keyclock server.
Steps/Actions:
Apps: unconfigured-demo apps built and deployed using maven.
When logging into keycloak I am getting “Forbidden”
JBWEB000065: HTTP Status 403 -
________________________________
JBWEB000309: type JBWEB000067: Status report
JBWEB000068: message
JBWEB000069: description JBWEB000123: Access to the specified resource has been forbidden.
________________________________
JBoss Web/7.2.2.Final-redhat-1
Following is the error I get on the keycloak console:
10:29:45,968 ERROR [io.undertow.request] (default task-45) UT005023: Exception handling request to /auth/realms/demo/tokens/access/codes: java.lang.RuntimeException: request path: /auth/realms/demo/tokens/access/codes
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:56) [keycloak-services-1.0-beta-3.jar:]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.0-beta-3.jar:]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:42) [keycloak-services-1.0-beta-3.jar:]
... 28 more
Caused by: java.lang.NullPointerException
at org.keycloak.models.jpa.ClientAdapter.validateSecret(ClientAdapter.java:142) [keycloak-model-jpa-1.0-beta-3.jar:]
at org.keycloak.services.resources.TokenService.authorizeClient(TokenService.java:779) [keycloak-services-1.0-beta-3.jar:]
at org.keycloak.services.resources.TokenService.accessCodeToToken(TokenService.java:665) [keycloak-services-1.0-beta-3.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]
at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) [resteasy-jaxrs-3.0.8.Final.jar:]
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.8.Final.jar:]
... 39 more
10:29:45,978 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-46) failed to turn code into token
10:29:45,979 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-46) status from server: 500
10 years, 5 months
PicketLink and KC Integration
by Pedro Igor Silva
Hi All,
Currently, I'm working in a new identity store to handle tokens issued by a specific IdP. KeyCloak is one of them.
So far, I'm trying to provide an easy way to integrate KC with PL. But it will also be useful for SAML-based apps.
My first use case is simple. A REST application provides endpoints protected by roles. The client application authenticates using an IdP (eg.: KC) and invoke the REST endpoints by sending the token on every single request. The application then validates, extract user information from the token and creates a security context for a specific request.
This identity store will operate in two modes:
1) Stateless. Useful for applications acting only as a Service Provider. In this case, the app only wants to join a SSO session and use all information provided by a token to perform in-house authorization such as RBAC. Tokens are not persisted and are usually short-lived.
2) Stateful. Useful for applications that want to use a specific token to invoke 3rd party APIs. In this case, the app wants to login using a social provider (eg.: facebook, github or even KC) and store the token and user information locally for later use. Once stored, the app can retrieve the token and use it to invoke an external API.
What I did so far is related with #1 and the functionality is covering:
- Usage of keycloak.js to redirect users to login page and renew tokens.
- Send KC token in every single request to a specific PL filter that knows how to process tokens.
- Validate the token and create a security context for an user. Considering KC, the validation involves the expiration time, signature, audience, issuer, etc.
- Extract from the token identity information such as username, roles, realm, etc.
- Support authorization checks based on the information extracted from a token.
I still have some gaps to fill, but I would like to know what are your thoughts about how PL and KC can work together. AFAIK, KeyCloak is more about authentication. If the application wants authorization based on the information from a token (eg.: roles) it must do it by itself. Or you guys already have code for that ?
Thanks.
Pedro Igor
10 years, 5 months
federation iteration 2
by Bill Burke
* UserProvider interface stayed the same
* Didn't add a UserFederation interface like I said I was going to,
didn't have to.
* UserFederationProvider interface no longer extends UserProvider and is
smaller
* UserFederationProvider no longer supports pagination
* UserFederationProvider no longer supports getUsers(). This is a very
dangerous method for large databases since we can't reliable support
pagination.
How does pagination work now?
* getUsers() only queries local storage
* search() methods will call searchByAttributes() on every provider.
Then paginate based on local storage. This may result in long query
times (and database inserts) depending how many people of the same name
there are. In a database of 1 million, not sure what the distribution
will be. For example, the most popular US name is "Smith" there are 2.8
million which is less than 1% of the USA.
But, I'm not sure what to do. Admins *MUST* be able to search based on
names. What would reduce the search would be to require both first and
last name.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 5 months
federation commited need feedback
by Bill Burke
First iteration is commited. I still have a lot to do.
* AuthenticationProvider currently co-exists with Federation. I will
delete it after the review of FederationProvider.
* UserModel is proxied. Some updates delegated to LDAP. Need to expand.
* Still need to do admin console UI for federation
* Still need to implement search and other queries for LDAP
* Still need to test disjoint credential type storage.
Feedback on unimplemented features for LDAP:
* registration supported switch.
* Importing username and email will be required. Everything else will
be optional. That cool?
* Modes for federation will be: READ_ONLY, SYNCED, and UNSYNCED.
SYNCED will update LDAP on demand. UNSYNCED will store changes locally
and require the user to handle synchronization themselves.
* Going to have an import-attributes on/off switch. A keycloak->ldap
attribute map will be required to be configured. If this switch is off,
UserModel proxy will load attributes on demand.
Questions:
* Is ExternalModelAuthProvider actually a feature requested by users?
I'd like to not have to do this. At least for 1.0.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 5 months
import/export should only use local storage
by Bill Burke
Import/export should only use local user storage correct?
FYI, there's going to end up being 3 interfaces for users.
* UserFederation -> top level API and entrypoint that will be used by
services
* UserProvider -> used for local storage
* UserFederationProvider -> used for federation.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 5 months
Wildfly integration
by Bruno Oliveira
Good morning guys, I'm banging my head against the wall with this issue:
https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what I'm trying to
do is integrate the latest changes on master with UPS on AeroGear.
On AS7 the application runs with no errors, but when I try to deploy on
Wildfly I get HTTP 400 after login.
Probably is some misconfiguration on my end, but I already double checked
project-integrations, checked the examples, tried to debug on IntelliJ and
Chrome.
Here are the steps to reproduce:
git clone git@github.com:keycloak/keycloak.git && cd keycloak && mvn
clean install -DskipTests=true -Dcheckstyle.skip=true
cd ..
git clone git@github.com:aerogear/aerogear-parent.git && cd
aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
cd ..
git clone git@github.com:aerogear/aerogear-unifiedpush-server.git && cd
aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
cp auth-server/target/auth-server.war
$JBOSS_HOME/standalone/deployments/
cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
$JBOSS_HOME/bin/standalone.sh
If you have an idea, let me know.
--
abstractj
PGP: 0x84DC9914
10 years, 5 months
Updates to access code
by Stian Thorgersen
I've completed all the pre-work required before storing AccessCode details in UserSessionProvider.
What's be done to AccessCode is:
* It no longer contains AccessToken. Instead it just contains the list of requested roles (intersection of client scope and user roles). The AccessToken is generated from this in the TokenService.codeToToken
* authMethod, usernameUsed and rememberMe has been moved to UserSessionModel
* list of RequiredActions have been changed to a single action. The action can be one of the required actions, oauth_grant, or nothing. A code can only be used for the action currently set on it. For example if the code is set to VERIFY_EMAIL that is the only thing it's useful for. Also added the oauth_grant action to make sure a user has verified the grants (if client obviously) before the code is active and can be used to obtain a token.
* expiration has been removed. Instead the timestamp and realm.getAccessCodeLifespan/getAccessCodeLifespanUserAction is used directly.
That's it. Next step is to the details in UserSessionProvider and only send the id as the code query param.
Question: is sending UUID + timestamp sufficient as the code, or should we sign it with JWSBuilder as well?
10 years, 5 months
Provider config
by Stian Thorgersen
We need to add a generic provider config mechanism. It should be possible to configure providers at two levels:
* Server - through keycloak-server.json
* Realm - through RealmProvider
With regards to server we already have this. It requires editing the keycloak-server.json and restarting the server. IMO that's fine for now, and we can consider adding support for doing this at runtime through the admin console in the future.
For realm config (which would be needed for ldap) I propose that we add a ProviderConfigModel to RealmProvider. The ProviderConfigModel consists of:
* RealmModel realm
* String spi
* String provider
* Map<String, String> config
We need to add an admin endpoints to add/update provider configs as well as making it possible to edit these through the admin console. We should add a method to the provider factory:
* List<ConfigOption> getConfigOptions - this will return the configuration options the provider can support
ConfigOption will include (we could also add support for validation):
* String key
* String label
On the admin console I propose we add a Provider config page. The page will list out all available SPIs, once you select an SPI it will list out all available providers. You can then click on individual providers to get a form to edit the provider config. The form will use the getConfigOptions to know what labels/input fields to add.
Further, we need to make some changes to KeycloakSession/ProviderFactory to support realm config. We could change ProviderFactory.create(KeycloakSession session) to ProviderFactory.create(KeycloakSession session, String realmId, Config.Scope realmConfig). This allows a provider to either share resources (i.e. connections) with multiple realms, or if it wants different connections per-realm it can handle that internally (for example in a map using realmId as the key).
10 years, 5 months