Commits/PRs
by Stian Thorgersen
Please squash commits. The ideal is one commit and one PR per JIRA issue.
If you want to break a JIRA issue into smaller tasks then please create
sub-tasks in JIRA, then do one commit/PR for one sub-task.
Always include JIRA key in the commit message. A good commit message look
example is:
----
KEYCLOAK-1267 add a separate sso_max_lifespan parameter for remember me
----
We have automated linking of PRs in JIRA as long as the JIRA key is
included in the commit message. It doesn't hurt to manually link as this is
generally quicker.
With JIRA key in commit and PRs linked in JIRA we get a good history that
is useful in the future to identify what was changed and why. It's also
important that this history goes both ways. For example if you don't
include JIRA key in commit it's very difficult to find the associated JIRA
issue. If you didn't even link the PR then it's pretty much impossible.
All commits to main repository should be done through PRs, no direct
pushing to repository please.
8 years, 1 month
master and 1.9.x branches
by Stian Thorgersen
Master is now ready to accept new features for 2.0.0.CR1. We won't be
adding any new features ourselves at the moment as our focus is testing and
bug fixing on 1.9.x. It's primarily intended for external contributions.
1.9.x branch is ready for fixes for 1.9.2.Final. At this point we should be
very careful about any changes to prevent regressions. We are NOT adding
any new features (unless acked by PM, QE, EM and project lead) in 1.9.x. We
also are going to be very careful about fixes and improvements to include
in 1.9.
JIRA issues will have fix version 1.9.2.Final and/or 2.0.0.CR1. If fix
version is only 2.0.0.CR1 then send PR to master. If fix version
is 1.9.2.Final and 2.0.0.CR1 send to both master and 1.9.x. My personal
flow for this is fix in master, then use "git cherry-pick <commit>" to add
to 1.9.x branch.
8 years, 1 month
Required Action Config?
by Josh Cain
Hi all,
I'm working on a required action that needs a bit of configuration. I'd
ideally like to manage this in the same way that I manage my current
federation provider/authenticator SPI implementations, but I don't see a
way to do so. Is there a way to configure these via Keycloak?
If not, I'm considering just writing said action as an authenticator and
including it in the authentication flow. Would there be any downsides to
this approach?
Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
8 years, 1 month
client creation using bearer token
by John Dennis
Chapter 9.1.1 of the Keycloak Reference Guide
(http://keycloak.github.io/docs/userguide/keycloak-server/html/index.html)
says that a bearer token can be used to register a client provided the
user has the create-client or manage-client role on the realm.
Chapter 6 discusses how to create a user in the master realm who can
administer a specific realm. I followed those instructions and created
a user and assigned them the create-client role in the desired realm.
I then obtained a token for that user by posting to
auth/realms/master/protocol/openid-connect/token with the username and
password for the realm administrator I created along with the
client-id of "admin-cli" (not sure if this is the right client id for
this purpose, can someone explain selecting the proper client id?).
I received back a token and then used this as an authorization bearer
token when POSTing to the
auth/realms/{realm}/clients/saml2-entity-descriptor to create a SAML
SP client in the realm. However this fails with an 403 Forbidden
response and the message "Invalid signature".
This error seems to be generated by the ClientRegistrationTokenUtils
class in the method parseToken() which is called in the init() method
of the ClientRegistrationAuth class. As far as I can tell the
parseToken() method is using the public key for the realm. But the
token is not from the realm, the token is from the master realm where
the realm's admin is located.
For the bearer token to work when registering a client it would seem
the token would have belong to a user in the realm, not the master
realm as discussed in Chapter 6.
How is client creation supposed to work with a bearer token instead of
using an initial access token?
--
John
8 years, 1 month
Support concurrent startup by more cluster nodes
by Marek Posolda
Send PR with added support for $subject .
https://github.com/keycloak/keycloak/pull/2332 .
Few details:
- Added DBLockProvider, which handles acquire and release of DB lock.
When lock is acquired, the cluster node2 needs to wait until node1
release the lock
- The lock is acquired at startup for the migrating model (both model
specific and generic migration), importing realms and adding initial
admin user. So this can be done always just by one node at a time.
- The lock is implemented at DB level, so it works even if infinispan
cluster is not correctly configured. For the JPA, I've added
implementation, which is reusing liquibase DB locking with the bugfix,
which prevented builtin liquibase lock to work correctly. I've added
implementation for Mongo too.
- Added DBLockTest, which simulates 20 threads racing for acquire lock
concurrently. It's passing with all databases.
- Default timeout for acquire lock is 900 seconds and the time for lock
recheck is 2 seconds. So if node2 is not able to acquire lock within 900
seconds, it fails to start. There is possibility to change in
keycloak-server.json. Is 900 seconds too much? I was thinking about the
case when there is some large realm file importing at startup.
Marek
8 years, 1 month
Remove auth-server-url-for-backend-requests from adapters
by Stian Thorgersen
Currently we allow adapters to configure two urls for Keycloak
(auth-server-url and auth-server-url-for-backend-requests). I propose we
remove auth-server-url-for-backend-requests.
The auth-server-url-for-backend-requests property was added as a way for
adapters to invoke Keycloak directly without having to go through a load
balancer or reverse proxy.
The issue with auth-server-url-for-backend-requests is that the Keycloak
server will not know the adapter is invoking Keycloak from a different URL,
which results in invalid URLs in tokens and also if any links are generated
(for example verify email).
It also means that there's a need to have two separate certificates
configured for Keycloak as there are different hostnames.
The currently proposed solution is to add a way to configure the hostname
for the Keycloak server. However, this is an extra configuration
requirement and is also a significant amount of work to implement as well
as potentially quite error prone. This could further be problematic if
there is indeed two valid URLs for a server (for example http://company.com
and http://internal.company.com).
We should simply remove auth-server-url-for-backend-requests. If anyone
wants to bypass the load balancer for internal machines that should be
solved at the DNS level or by adding entries to the host file. As the
hostname remains the same there's no need for multiple certificates, nor is
there a need to hardcode the address on the Keycloak server itself.
8 years, 1 month
Should we add version to JSON during export?
by Marek Posolda
Currently there is an issue, that when we import JSON file, we don't
know in which Keycloak version was this JSON file exported. This can
cause some issues. For example you don't know which builtin objects
exactly you should add - some example in the JIRA:
https://issues.jboss.org/browse/KEYCLOAK-1982
Adding version may not help in all cases as there is also hand-written
JSON files and partial-import etc, so you don't know if version is
really presented in the imported JSON file. On the other hand, in some
cases it may be helpful.
Question is, should we aim to add it to 1.9.2?
Marek
8 years, 1 month
Re: [keycloak-dev] [keycloak-user] Best practices for securing sign-in on mobile
by Stian Thorgersen
Have you tried AppAuth with Keycloak? If so I'd love to know how you got on
with it.
On 7 March 2016 at 18:28, Jason Axley <jaxley(a)expedia.com> wrote:
> The Google Identity team just open sourced some Open ID Connect libraries
> that use In-app tabs on Android and SFSafariViewController on iOS for
> secure, streamlined web workflows in-app.
>
> https://openid.github.io/AppAuth-Android
> https://openid.github.io/AppAuth-iOS
>
> -Jason
>
> From: <keycloak-user-bounces(a)lists.jboss.org> on behalf of Stian
> Thorgersen <sthorger(a)redhat.com>
> Reply-To: "stian(a)redhat.com" <stian(a)redhat.com>
> Date: Monday, March 7, 2016 at 12:11 AM
> To: keycloak-dev <keycloak-dev(a)lists.jboss.org>, "
> keycloak-user(a)lists.jboss.org" <keycloak-user(a)lists.jboss.org>
> Subject: [keycloak-user] Best practices for securing sign-in on mobile
>
> Our Cordova apapter uses a webview (via cordova-plugin-inappbrowser) to
> open the login page. This results in no SSO between applications and it
> also has some security implications. A better approach is to use in app
> browser tabs when supported or fallback to the system browser.
>
> See https://www.youtube.com/watch?v=ppeU8yeI_ks for more details.
>
8 years, 1 month
