Keycloak High-Availability / Database
by Stefan Schlesinger
Hello Folks!
I tried to setup a Keycloak HA cluster with Percona XtraDB/Galera as HA database backend and it looks like its not currently supported, at least by the database schema Keycloak uses and the default Galera settings. Galera requires or recommends (performance) all table schemas to be defined with a primary key field and when I tried to add a role to a group I got the following error:
ERROR [io.undertow.request] (default task-14) UT005023: Exception handling request to /auth/admin/realms/vault/groups/c2a04652-a322-1111-18ea-b2145bab2222/role-mappings/realm: org.jboss.resteasy.spi.UnhandledException: org.keycloak.models.ModelException: org.hibernate.exception.GenericJDBCException: could not execute statement
...
Caused by: org.keycloak.models.ModelException: org.hibernate.exception.GenericJDBCException: could not execute statement
...
Caused by: org.hibernate.exception.GenericJDBCException: could not execute statement
...
Caused by: java.sql.SQLException: Percona-XtraDB-Cluster prohibits use of DML command on a table (keycloak.ADMIN_EVENT_ENTITY) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER
Looking through the database schema the following tables don’t have a primary key defined:
ADMIN_EVENT_ENTITY
COMPOSITE_ROLE*
CREDENTIAL_ATTRIBUTE
DATABASECHANGELOG
FED_CREDENTIAL_ATTRIBUTE
REALM_ENABLED_EVENT_TYPES*
REALM_EVENTS_LISTENERS*
REALM_SUPPORTED_LOCALES*
REDIRECT_URIS*
WEB_ORIGINS*
Tables marked with an asterisk don’t even have an ID field, the rest of the tables actually got an ID field (with a UUID 'primary key'), which I think could be easily defined as primary key, and could easily be added.
Looking at the Percona documentation[1][2], the limitation to only support tables with primary keys was liftet in more recent versions with the introduction of wsrep_certify_nonPK. However, it's still generally a best practice to have explicit PKs. If you don't define a PK, Galera will use an implicit hidden 6-byte PK for Innodb tables, taking up space that you can't use for querying. Innodb is very much optimized towards PK lookups.
Also I’d need to set pxc_strict_mode from ENFORCING to PERMISSIVE, but that might have other side effects, as it relaxes other validations as well. Any experiences?
Also, would it be possible to add primary keys in a bugfix version?
Best,
Stefan.
[1] - https://www.percona.com/doc/percona-xtradb-cluster/5.7/features/pxc-stric...
[2] - https://www.percona.com/doc/percona-xtradb-cluster/5.7/wsrep-system-index...
8 years, 7 months
Elytron Adapter
by Pedro Igor Silva
Hello,
I'm starting to finish up some tests with the new Elytron Adapters for OIDC
and SAML. The idea is push the adapter as soon as I prepare arquillian
testsuite to run against a container using Elytron.
Until now, I was using integration tests to test these adapters. But for
now on, I'll be running all arquillian tests as suggested by Stian. Results
are pretty good so far, there is a single test failure right now
(org.keycloak.testsuite.adapter.servlet.AbstractDemoServletsAdapterTest#historyOfAccessResourceTest)
which I need to figure out what is going on.
We are going to have a specific profile to test Elytron adapters. This
profile is configured to run a WFLY 11 SNAPSHOT.
I've already discussed this topic with Stian and the idea is to create a
baseline for Elytron adapters as well start preparing Keycloak for Wildfly
11 and the new security infrastructure provided by Elytron.
This *does not* mean that we are replacing undertow adapters. But just
preparing our adapters code base to the next WFLY release (and EAP 7).
I'll probably send a PR on friday or early next week.
Please, let me know if you have any questions about this work.
Regards.
Pedro Igor
8 years, 7 months
Re: [keycloak-dev] New Account Management Console and Account REST api
by Thomas Connolly
Hi All
Could this UI and API be put on a separate port please?
RegardsTom.-----------------------------------
Message: 1Date: Fri, 17 Mar 2017 08:25:47 -0700
From: Tair Sabirgaliev <tair.sabirgaliev(a)gmail.com>
Subject: Re: [keycloak-dev] New Account Management Console and Account
REST api
To: Stan Silvert <ssilvert(a)redhat.com>, stian(a)redhat.com
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
Message-ID:
<CAGU3vRfYkUjsoZMdyTz25HFAE0+P+Yfn69X1wG1_SdBqNwAW3w(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
+1 for Angular2, this will make maintenance and customisation easier.
The framework becomes very popular and close to ?JavaEE mindset?.
On 17 March 2017 at 18:19:23, Stan Silvert (ssilvert(a)redhat.com) wrote:
On 3/17/2017 8:09 AM, Stian Thorgersen wrote:
> Had another idea. We could quite easily make it possible to configure
> the "account management url" for a realm. That would let folks
> redirect to external account management console if they want to
> completely override it.
That would also mean that our own account management console could be
served from anywhere or even installed locally on the client machine.
>
> On 17 March 2017 at 13:08, Stian Thorgersen <sthorger(a)redhat.com
> <mailto:sthorger@redhat.com>> wrote:
>
> I'm going to call it "YetAnotherJsFramework" ;)
>
> On 17 March 2017 at 12:54, Stan Silvert <ssilvert(a)redhat.com
> <mailto:ssilvert@redhat.com>> wrote:
>
> On 3/17/2017 5:47 AM, Stian Thorgersen wrote:
> > As we've discussed a few times now the plan is to do a brand
> new account
> > management console. Instead of old school forms it will be
> all modern using
> > HTML5, AngularJS and REST endpoints.
> One thing. That should be "Angular", not "AngularJS". Just to
> educate everyone, here is what's going on in Angular-land:
>
> AngularJS is the old framework we used for the admin console.
> Angular is the new framework we will use for the account
> management console.
>
> Most of you know the new framework as Angular2 or ng-2, but
> the powers
> that be want to just call it "Angular". This framework is
> completely
> rewritten and really has no relation to AngularJS, except they
> both come
> from Google and both have "Angular" in the name.
>
> To avoid confusion, I'm going to call it "Angualr2" for the
> foreseeable
> future.
> >
> > The JIRA for this work is:
> > https://issues.jboss.org/browse/KEYCLOAK-1250
> <https://issues.jboss.org/browse/KEYCLOAK-1250>
> >
> > We where hoping to get some help from the professional UXP
> folks for this,
> > but it looks like that may take some time. In the mean time
> the plan is to
> > base it on the following template:
> >
> >
> https://rawgit.com/andresgalante/kc-user/master/layout-alt-fixed.html#
> <https://rawgit.com/andresgalante/kc-user/master/layout-alt-fixed.html#>
> >
> > Also, we'll try to use some newer things from PatternFly
> patterns to
> > improve the screens.
> >
> > First pass will have the same functionality and behavior as
> the old account
> > management console. Second pass will be to improve the
> usability (pages
> > like linking, sessions and history are not very nice).
> >
> > We will deprecate the old FreeMarker/forms way of doing
> things, but keep it
> > around so it doesn't break what people are already doing.
> This can be
> > removed in the future (probably RHSSO 8.0?).
> >
> > We'll also need to provide full rest endpoints for the
> account management
> > console. I'll work on that, while Stan works on the UI.
> >
> > As the account management console will be a pure HTML5 and
> JS app anyone
> > can completely replace it with a theme. They can also
> customize it a lot.
> > We'll also need to make sure it's easy to add additional
> pages/sections.
> >
> > Rather than just add to AccountService I'm going to rename that
> > to DeprecatedAccountFormService remove all REST from there
> and add a new
> > AccountService that only does REST. All features available
> through forms at
> > the moment will be available as REST API, with the exception
> of account
> > linking which will be done through Bills work that was
> introduced in 3.0
> > that allows applications to initiate the account linking.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8 years, 7 months
initial fine-grain admin permissions
by Bill Burke
Here's what we want to be able to manage for fine-grain admin
permissions for the 1st iteration. If you think we need more, let me
know, but I want to keep this list as small as possible.
User management
* Admin can only apply certain roles to a user
* Admin can view users of a specific group
* Admin can manage users of a specific group (creds, role mappings, etc)
Group Management
* Admin can only manage a specific group
* Admin can only apply certain roles to a group
* Admin can only manage attributes of a specific group
* Admin can control group membership (add/remove members)
Client management:
* Admin can only manage a specific client.
* Admin can manage only configuration for a specific client and not
scope mappings or mappers. We have this distinction so that rogues
can't expand the scope of the client beyond what it is allowed to.
* Service accounts can manage the configuration of the client by default?
8 years, 7 months
ResourceFactory SPI for AuthZ service
by Bill Burke
I want to use AuthZ service to implement fine-grain admin console
permissions. To do this, I foresee that I'll have to define resources
that correspond one to one to objects in the Keycloak domain model.
Specifically roles, groups, and clients. There are a few problems with
this approach:
* Some deployments of keycloak have tens of thousands of roles and
groups or hundreds of clients
* Synchronizing an AuthZ resource that represents a role, group, etc.
must be done. i.e. when role/group/client is removed or renamed.
* I'd like for policies to be able to have the real object that the
resource represents when evaluating policies
I want to suggest something similar that we've done with User Storage
SPI in that links to AuthZ resources are a "smart" id.
"f:" + providerId + ":" + resource id
When evaluating policies the engine would navigate to a provider that
could load an instance of the Resource interface. This way I could
represent a role or group as an AuthZ resource without creating a
resource in the Authz datamodel. Am I making sense?
Bill
8 years, 7 months
Question on securing teiid with keycloak
by Shankar_Bhaskaran
Hi ,
I am trying to secure teiid/jdbc and odata using keycloak . I have a secure domain defined as follows but doesn't seem to work for direct access(jdbc from squirrel) . If I remove org.keycloak.adapters.jboss.KeycloakLoginModule it seem to work fine.
<security-domain name="keycloak">
<authentication>
<login-module code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/>
<login-module code="org.teiid.jboss.PassthroughIdentityLoginModule" flag="required" module="org.jboss.teiid"/>
<login-module code="org.keycloak.adapters.jaas.DirectAccessGrantsLoginModule" flag="optional" module="org.keycloak.keycloak-adapter-core">
<module-option name="keycloak-config-file" value="${jboss.server.config.dir}/keycloak-dsis-data.json"/>
<module-option name="password-stacking" value="useFirstPass"/>
</login-module>
</authentication>
</security-domain>
Regards,
Shankar
8 years, 7 months
How to increase the log level of Keycloak
by Tech
Dear experts,
we are working with Keycloak 2.5.1 and we configured a OIDC resource.
While we are connecting from outside, Keycloak returns a 400 (detected
from our application), but we don't see this error reflected into the
console and we are not able to increase the log level of Keycloak.
We checked some parameters into
/standalone/configuration/standalone.xml, we changed the console-handler
to "FINEST", but we still don't get any needed log.
Could you please advise?
Thanks!
8 years, 7 months
Authorization code and refresh tokens in cross DC
by Stian Thorgersen
One problem with authorization codes and refresh tokens in cross DC setups
is the fact that they are supposed to be one-time only.
We could have an option on a realm to set if they are one-time or not (we
already do for refresh tokens). If they are one-time we have a separate
synchronously replicated cache to handle.
Question though would it be acceptable that they are not one-time? It does
imposed a certain risk as it wouldn't be possible to detect if they are
leaked.
For example imagine someone somehow manages to sniff all codes sent to an
application (say it's a public application since that doesn't require
credentials). They can then exchange the code for tokens alongside the real
application. As the codes are not one-time this goes undetected. If codes
on the other hand are undetected the realm application will either be the
only one to exchange the code, or it will notice something is not right.
This issue may be resolved by the introduction of Proof Key for Code
Exchange [1] though.
For refresh tokens sure it would be nice to be able to detect leakage, but
one-time is fairly brittle as HTTP requests are not transactional so you
can easily end up with loosing a response which would render the old
refresh token useless and the new one lost.
[1] https://tools.ietf.org/html/rfc7636
8 years, 7 months
JWS sizes
by Bill Burke
FYI,
Signature for RSA-Sha-256 for JWS is 172 bytes. The Header of the JWS
is minimally 20 extra bytes. Can be more depending on additional
headers (kid, typ, cty). Wanted to state these numbers as they effect
if we want to use a cookie to store session information instead of
within a ClientSessionModel on the auth server, or HttpSession on
clients/apps. Supposedly cookie storage is limited to 4k per domain, so
we're immediately starting 200 bytes (5%) in the hole.
Bill
8 years, 7 months
