1.2.0.CR1 release on Wednesday
by Stian Thorgersen
I'd like to release 1.2.0.CR1 on Wednesday (or Thursday at the latest!).
Remaining work:
* KEYCLOAK-1229 Re-enable broker examples - Bill can you look at this?
* KEYCLOAK-1189 SSLPeerUnverifiedException when deploying Keycloak with JDK 8 - I'm looking at this ATM, testing if including a httpcomponents module with slot=4.3 works
* KEYCLOAK-1180 keycloak proxy needs different redirect uri config - Bill can you look at this? Or shall we just post-pone it?
* KEYCLOAK-1040 Allow import of realm keys (like we do for SAML) - shall we post-pone this?
* KEYCLOAK-1070 Persist client grants - almost done
I'd also like to do "KEYCLOAK-887 Use standard RCUE or Patternfly theme by default", basically changing l&f of admin console to better match standard PatternFly. Ideally this would be done prior to 1.2.0.CR1 release, but I'm not sure how long it'll take. If IO can finish this tomorrow I'll include it, if not I'll post-pone it.
Anything else? Would be great if everyone can look at distribution changes I did and comment/complain about it ASAP!
We'll follow-up with a 1.2.0.Final next week.
10 years, 11 months
Oidc bug?
by Raghu Prabhala
Bill,
Sometime back I mentioned to you that I used to get a "connect refused" from KC when I tried the token end point.
I think I am able to simulate it more often using 1.2 beta release - it happens randomly if you follow the below steps
1) open up browser and try the basic flow 3 or 4 times. Then close the browser
2) repeat the above 3 or 4 times and you may see the issue
I believe it is due to the sessions KC creates. Clearing the session from admin gui will address the issue.
Unfortunately the logs do not show anything - is there any configuration that will help me gather more info?
Thanks
Raghu
Sent from my iPhone
10 years, 11 months
Sharing HttpClient in backchannelLogout
by Marek Posolda
Looks that both OIDCLoginProtocol.backchannelLogout and
SamlProtocol.backchannelLogout always create new instance of Apache
HttpClient used just during single invocation. I suspect this is not
very good for performance as HTTP connections pool needs to be always
created again and again? We're doing it even if client doesn't have
adminUrl (no sending of HTTP request is even needed).
I wonder if we should share single instance of HttpClient (or
ApacheHttpClient4Executor) per LoginProtocolFactory? Or even better, if
we convert AuthenticationManager to the SPI (which is planned AFAIK) and
pass the executor from there?
Marek
10 years, 11 months
Documentation for the list of parameters of JSON file for realm creation
by Shiva Saxena
Hi Everyone,
I saw a good number of github example where we can create realms in
keycloak, via uploading a JSON.
Unfortunately I wan unable to find any documentation that lists the
parameters we can put in this JSON file to customize the realm.
Can some body guide me to some documentation that lists the list of
parameters we can pass for realm creation.
--
Thanks & Regards
Shiva Saxena
10 years, 12 months
Identity Brokering token storage and retrieval
by Stian Thorgersen
We've already discussed this, but didn't come to a conclusion.
There's two separate use-cases to consider:
1. Authentication
2. Offline access
For simplicity the examples below assumes OpenID Connect, but same logic applies to SAML.
Authentication
--------------
In this case user authenticates using an external IdP. After the user has authenticated the access and refresh (if available) tokens are stored in user session. Tokens are automatically refreshed by Keycloak to support brokered log out. In this case an application can only retrieve an access token for the identity provider that was used to authenticate the user.
Offline access
--------------
In this case we should add the option "offline access" to the provider config. When enabled we add "offline" to the requested scope. When a user first logs in or links through account mngmt we store the refresh token (aka "offline token") in the user store. As this is a long term token I don't see any problems using the user store for it. In this case an application can retrieve an access token for the identity provider that was used to authenticate the user, but also for an identity providers what have "offline access" enabled and there's an token store in the user store. One issue with this approach is that brokered log out doesn't work. A potential solution to that is that we only request offline access when linking the account, but during authentication don't add the offline scope and use the process from the first use-case.
Token retrieval
---------------
We add a "token service" client to Keycloak that has a "retrieve token" role for each provider. For an application to be able to retrieve the token the user has to have a role mapping on this role and the client has to have a scope on it as well. This results in using standard roles, scopes and consent screens instead of a different mechanism.
For 1.2.0 we should only add support for the "Authentication" use case. I believe we pretty much already have this as Bill did this to support brokered log out. Only thing we need to change is how we manage if a client has access to retrieve the token or not. We should just jira the other use-case and add if it's requested by users.
10 years, 12 months
Implicit Flow
by Fadi Abdin
Does anyone know if the OAuth2 implicit flow on keycloak is supported ?
I am trying to retrieve the access_token directly after logging in. Ideally
it should work if you send response_type=token , but it always returns a
code=... no matter what is the response_type ..
Does anyone know how to get this to work or if its even supported ?
Thanks,
Fadi
10 years, 12 months
Keycloak distribution changes
by Stian Thorgersen
We've discussed this and I hope we're all on the same page, but just to confirm here's what we've discussed:
Keycloak Server
---------------
* Standalone
- Built on WildFly servlet-only
- No 'standalone/deployments' directory
- Includes server only sub-system
- Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc, included)
- Keycloak deployed to root context (http://localhost:8080)
* Demo Bundle
- Built on WildFly full
- Includes demo ready deployed and configured
- Includes server and adapter sub-systems
- Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs, examples, etc.)
- Keycloak deployed to auth context (http://localhost:8080/auth)
* Installer
- Installs Keycloak server sub-system into existing WildFly
- Only "latests" WildFly at the time of release is supported
- Keycloak deployed to auth context (http://localhost:8080/auth)
Keycloak Embedded
------------------
* Consumed by external JBoss projects to embed Keycloak
* Build-your-own WAR example repo
Keycloak Adapters
-----------------
* Separate download from server
* Installer for WildFly subsystem adapter
* We still have to decide if adapters should have a separate release cycle/version to the server
* We still have to decide if Java adapters should be moved to separate github repo
Finally, a set of releated tasks
--------------------------------
* Split subsystem into server and adapter
* Use standalone.xml instead keycloak-server.json (json will still be supported for embedded)
* Add support to use dmr/jboss-cli for configuring the server (for example a single jboss-cli batch script can add data-source and set Keycloak to use it)
* Add support to use dmr/jboss-cli for configure realms, apps and users
* Add support to use root-context with server subsystem
10 years, 12 months
generic migration?
by Bill Burke
Do we have a way to plug in generic version migration? I need to add a
ClientModel and a role for that ClientModel. Right now it looks like I
have to do it manually for JDBC and Mongo.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years, 12 months
