Reloading KeyCloak on the fly
by Mitya
Hi,
I'm developing a KeyCloak extension which is packaged as two JBoss
modules:
- the extension proper (custom authenticator + custom realm resource +
custom admin theme);
- modified org.keycloak.keycloak-model-jpa (since Entity SPI is not yet
available).
Each time I make changes, I have to go through a roundabout of stopping
KeyCloak, deploying modules and starting KeyCloak again. This can
happen as many as several dozen times a day; as soon as I roll a CI
infrastructure, the build server will have to do the same. Needless to
say, the process is pretty time-consuming; additionally, I'll have to
grant permissions to the build server to restart a system service
(KeyCloak is deployed as systemd unit). I've tried the following in
jboss-cli:
[disconnected /] connect
[standalone@localhost:9990 /] module remove --name=foo.bar.main
[standalone@localhost:9990 /] module add --name=foo.bar.main --
resources=... --dependencies=...
[standalone@localhost:9990 /] reload
This doesn't help, despite WildFly reports to have redeployed and
restarted KeyCloak. The updated modules are simply not picked up.
Am I missing something? KeyCloak developers, what would you recommend
to speed-up the workflow?
Cheers,
Mitya
7 years, 10 months
Keycloak commit message format
by Thomas Darimont
Hello group,
it's just a minor thing and sorry to ask that as an outsider
but I was wondering whether you could agree on a standard for commit
messages that reference JIRA issues.
In the git log one sees variants like:
KEYCLOAK-XXX 1st line of commit message
KEYCLOAK-XXX: 1st line of commit message
KEYCLOAK-XXX - 1st line of commit message
[KEYCLOAK-XXX] - 1st line of commit message
Would be great if you guys could agree on a style != freestyle :)
Cheers,
Thomas
PS:
I use the git alias lg to glance over the keycloak log
alias.lg=log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset
%s %Cgreen(%cr) %C(yellow)<%an - %ae>%Creset' --abbrev-commit
--date=relative
7 years, 10 months
AJP port and port-offset
by John Dennis
In the past we had been using HTTP and utilizing
jboss.socket.binding.port-offset to move the port to a higher number.
But now we're using AJP and the port-offset does not seem to apply to
the ajp port. Is this expected?
--
John
7 years, 10 months
Re: [keycloak-dev] Feedback
by Pedro Igor Silva
Hi All,
Asked Bill for some feedback about AuthZ docs [1] and would like to share with you.
@Bill, my initial comments inline.
[1] https://keycloak.gitbooks.io/authorization-services-guide/content/
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Pedro Igor Silva" <psilva(a)redhat.com>
> Sent: Wednesday, June 8, 2016 11:15:03 AM
> Subject: Re: Feedback
>
> * Example is too complex. Needs to be broken down and explained for
> each policy that was created.
OK. By "broken down" you mean using sub-topics (pages) or just sections on the same page ?
The "Hello World" one should be fine because it is just a single policy example. The "Securing a Servlet Application" may have more details about each of those policies, will work on that. Or even just point to their respective documentation, as we also have doc for each policy type.
>
> * Example should not use JSON import. It should walk through screen
> shots to explain how to set up things.
The idea behind using JSON import is that it provides an easy and fast way to users get started. After all, you just need to copy&paste configuration (or obtain from examples dir) and import to KC. IMO, that makes the tutorial more easy to follow with focus on the main concepts being explained.
I'm trying to keep documentation about UI on each topic, so you can see how to use admin console to create/configure things.
>
> * Need more screenshots throughout doc
Probably related with your previous feedback. I'm going to take some more screenshots ....
>
> * Is Resource Server->Client always a one-to-one thing?
No, RS<->Client is not always a 1:1 mapping. Usually, they would be different entities, where the client is acting on behalf of the RO to access protected resources on a resource server. That is true for most API security use cases.
However, an app may use both hats. For instance, monolithic JEE apps.
>Maybe Authorization should move under clients tab?
That is a good question. And my quick answer for that would be to keep it separated for now.
I think changes like that may involve more discussions around UI design. For instance, today clients and resource servers are managed in the same space (Clients in left menu bar). As you know, clients (entities accessing a RS on behalf of an user) and RSs are different things and although they share a lot of things, I think we could have have them *visually* separated somehow.
AuthZ includes more tabs and flows, so I don't think move under clients tab would be a good idea. I'm not a UX expert, there is probably a way to do what you want nicely ...
>
> * Looks like there is a bit of redundant config for adapters. How big is
> authz at the adapter side?
>From an adapter perspective, AuthZ code is pretty much straightforward and small. The redundant config you are talking about is probably the "client" property in keycloak-authz.json. So yes, it is.
Today, authz code is basically provided by a Servlet Filter. See Policy Enforcers.
> Maybe this code should be merged with our
> adapters so config for user becomes simpler?
Well, I was trying to avoid change adapters. At least for now.
We can get those changes merged with our OIDC adapters, for sure. So I could move that *enforcer* property to a keycloak.json file.
The question is if we should just leave that way for now and release this stuff. It is your call, if you want them merged I'll do it.
> Something to think about
> and look into. Really probably depends how many dependencies authz
> brings in.
There is no additional deps ...
>
> * Need to unify scripting and SPI objects. Authz should share SPI
> objects (i.e. client IP address) with AuthenticationFlow SPI and other
> things. Looks like you might have duplicate things.
Saw that you merged some scripting stuff to authentication flow recently. But I'm not sure about have both authc and authz sharing the same SPI right now.
I don't think I'm replicating things. We are basically exposing a Evaluation API (that should be as simple as possible) that users can use to build rule-based policyes (eg.: JS, Drools, etc). Here are basically ABAC and policies can obtain
information using both identities and environment/runtime attributes.
For instance, whatever you put in a access token (eg.: using a protocol mapper) would be available as an attribute. Thus, available to policies.
>
>
> On 6/7/16 4:40 PM, Pedro Igor Silva wrote:
> > Hey Bill !
> >
> > When you get some time, could you please take a quick look at
> > https://keycloak.gitbooks.io/authorization-services-guide/content/index.html.
> >
> > There you will find the documentation for AuthZ Services and what I've
> > documented so far.
> >
> > Your feedback is really appreciated :)
> >
> > Thanks.
> > Pedro Igor
>
>
7 years, 10 months
Russian localization
by Nekrasov Aleksandr
Hi all,
I have translated all base theme message resources to russian language and want to create PR.
I believe, it will be good, if keycloak will be supports russian locale. How do you think?
Nekrasov Aleksander,
Developer,
Center of Financial Techologies
7 years, 10 months
Config File for token validator endpoints url in keycloak?
by Eric Son 3016
Hi,
I would like to use external token validator with the keycloak.
Is there any existing configuration file for storing token validator API endpoints url and its public key info?
I want to set them up in "System level" rather than the "Execution level" in the code.
Thanks for the help!
Best Regards,
WJ
7 years, 10 months
Proof of Concept for User Activity Dashboard
by Thomas Darimont
Hello group,
a few months ago I raised the feature request "Activity dashboard" in the
Keycloak JIRA.
https://issues.jboss.org/browse/KEYCLOAK-1840
This weekend I gave this a spin and I think I got pretty far with it,
see attached annotated screenshot.
The idea was to leverage the information from the stored event data
to compute some Keycloak usage statistics over time.
My current prototype supports JPA (user / event) storage provider
and works with postgresql but could be adapted to other databases including
MongoDB.
Since I need to compute the usage statistics based on the event data,
events need to be stored and some views (3) need to be defined to
make the data accessible from JPA in a generic fashion.
Since the queries are quite complex I wanted to keep them out
of the code and therefore used named native queries via orm.xml.
The actual queries use some database specific date/time functions
that I wanted to keep out of the code - thus I created views
that could be adapted for each database and provisioned via liquibase.
The view definitions can be found here:
https://gist.github.com/thomasdarimont/24e11be101c6ed8773f22e1defc5d66e
For MongoDB one could define appropriate aggregation framework pipelines
to express the same query logic.
I basically exposed the data from those views per realm via a newly
introduced AnalyticsProvider interface that is accessible via
KeycloakSession.
Data from this AnalyticsProvider is then exposed as a REST resource called
"DashboardResource".
Data from this REST endpoint is then consumed by the admin frontend in a
new section
called "dashboard".
In the frontend I used basic patternfly components, e.g.: cards & tables:
https://rawgit.com/patternfly/patternfly/master/tests/cards.html
For the heatmap I used http://cal-heatmap.com/#start which is based on d3js.
There is also an angularjs directive that could be used as well.
https://github.com/shekhargulati/angular-cal-heatmap-directive
The current hacky code can be found here.:
https://github.com/thomasdarimont/keycloak/commits/poc/KEYCLOAK-1840-dash...
The relevant commit is:
https://github.com/thomasdarimont/keycloak/commit/40a7956f8e547edc148d2dd...
The code still needs a decent amount of polishing but I wanted to share
this with
you guys first to see if this could make it into Keycloak at some point.
Cheers,
Thomas
7 years, 10 months
Narrowed down event subjects for AdminEvents
by Thomas Darimont
Hello Group,
when writing custom EventListeners for propagating Keycloak Events to
inform downstream systems
of any user related changes one also needs to consider events that are
caused by admins, e.g. AdminEvent.
Examples are the grant / revoke of a role, group membership changes
(derived roles) or user account changes
performed by an admin user.
Currently it is not possible to differentiate those admin events when
looking at the AdminEvent object
without actually parsing / inspecting the representation. This makes it
rather complicated to correctly react
specfic ways for an AdminEvent, e.g. on a Role Membership change, detect
and resolve the new role, the user involved and propagate that to the
downstream systems.
With https://issues.jboss.org/browse/KEYCLOAK-2961 I tried a simple
workround by adding the
actual realm resource paths to the AdminEvent objekt which allows me to
deduce what actually happend.
Since the associated PR (https://github.com/keycloak/keycloak/pull/2774)
was rejected I think a better solution would be to add dedicated "Event
Subject" Information to the AdminEvents.
Marek agreed that this would be a good idea in the PR discussion.
Subjects could be an enum with "ROLE", "USER/ACCOUNT", "GROUP", however for
ROLE one would need to differentiate between REALM_ROLE / CLIENT_ROLE (for
proper lookup) and ROLE creation and ROLE_ASSIGNEMNT, same with GROUP.
Together with the AdminEvent#OperationType one could deduce what happended,
e.g.:
Event Subject: ROLE_ASSIGNMENT
Event OperationType: CREATE
-> role was granted
Event Subject: ROLE_ASSIGNMENT
Event OperationType: DELETE
-> role was revoked
It would be great if the event would carry some narrowed context
information (OperationContext?),
e.g. in case of a CLIENT_ROLE ROLE_ASSIGNMENT: clientId, roleId, userId
Cheers,
Thomas
7 years, 10 months
Support for arbitrary byte arrays as HOTP keys
by Mitya
The current KeyCloak HOTP implementation assumes that a HOTP key (aka
seed, aka initialization vector) is stored as string, and thus contains
only printable characters. However, the HOTP standard (RFC 4226)
doesn't impose any restrictions on key material; any arbitrary byte
array is acceptable.
Moreover, many hardware HOTP tokens are pre-programmed at the factory,
and do contain non-printable seeds. Even though KeyCloak doesn't
support hardware tokens out of the box, developers could implement it
by extending KeyCloak and employing existing algorithms. Unfortunately,
the existing convention (to store HOTP seeds as printable strings)
makes this impossible.
For the "password" credential type, the "value" field is already stored
as Base64. I think "hotp" credentials could also be stored as Base64 or
hex; another option would be to store the "value" field as BLOB (like
it's already done for the "salt" field).
I think I could produce a PR for this, I only need to know which
scenario is preferred.
Cheers,
Mitya
7 years, 10 months
OIDC and SCIM
by Pedro Igor Silva
There are some initial discussions going on at OpenID Connect WG about SCIM.
Probably something to start tracking ....
Regards.
Pedro Igor
7 years, 10 months
