Keycloak OIDC Adapter and XMLHttpRequest
by Pedro Igor Silva
Hi All and sorry for the long email.
As you know, most AJAX frameworks send a X-Requested-With request header. This header is quite useful if you want to handle AJAX requests differently than ordinary HTTP requests.
For most cases, the keycloak.js is the perfect tool to enable user authentication and token management to a client application using HTML5+AJAX. However, we may find use cases where client configuration is restricted and you can't change it very deeply to integrate with Keycloak.
Well, yes. These are requirements from WildFly/EAP Console (a.k.a HAL) :)
If you are not familiar about how the console works from a security PoV, you just need to know that there is no specific configuration to secure the console itself, but to secure the Domain Management API. In other words, the console isn't protected at all and relies on the policies defined to the Domain Management API and on the authentication that is performed by the browser (eg.: DIGEST).
(There are some reasons why the console isn't protected by the server. For instance, the server is only concerned about protecting the domain management API and also that the console is just one more client that can talk with that API.)
The console is basically a GWT application using XMLHttpRequest to send requests to the server, where these requests are only accepted if they have some authentication/identity cookie (DIGEST, BASIC or Keycloak Identity Cookie) which can be handled by the browser and added to every single request to the server.
Thanks to Elytron, we can now protect the Domain Management API with any HTTP mechanism we want without having to change wildfly-core or any other part of the server. In the past few days I've been working on a Keycloak OIDC Adapter based on Elytron APIs and using it to protected the Domain Management API using bearer tokens, which is working nicely. However, using the same adapter, we must also be able to "protect" the console and enable SSO. Which requires a different type of authentication based on a redirection-based flow (Authorization Code Grant).
The XMLHttpRequest imposes some restrictions on how redirects can be handled, what makes hard to handle 302 status code and redirect the user to another resource. That said, I would like to propose a change to Keycloak OIDC adapters in order to better support XMLHttpRequest requests:
- The adapter checks if the request contains a X-Requested-With=XMLHttpRequest. If so, returns a response with a 403 status code and an Authorization header as follows:
Authorization: as_uri="http://localhost:8081/auth/realms/elytron/protocol/openid-connect/auth?re..."
Where "as_uri" can be used by the client to actually redirect the user to the authorization server / keycloak server.
The reason for a 403 and not a 401 is that some browsers will show a dialog if the server responds with a 401. So we are basically telling the client that the request was forbidden and that it must use "as_uri" to ask for authorization.
One important thing about this approach is that is up to server to tell to the client where the authorization server is and how it should ask for authorization. The client is pretty much decoupled from the authorization server and just need to know about how to handle the Authorization header with the "as_uri" parameter.
Any thoughts ?
Regards.
Pedro Igor
10 years
got detached from git branch? How?
by Bill Burke
Ok,
I've been struggling with GIT today. For some reason, my 1.9.x branch
clone and my master clone got detached. I'm assuming it is because of
the rebasing I did as this has never happened to me before...
So on that note...screw this rebasing shit. I'm sick of wasting time
re-applying commits every time I screw things up. I'm just too stupid
and incompetent to use this feature of git.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
10 years
2 Groups with same name?
by Stan Silvert
We currently allow more than one group to have the same name. I realize
that this is probably due to the fact that groups are hierarchical and
you might want the same group name at different levels.
However, right now there are no restrictions at all. You can have as
many "foo" groups as you like even if they have the same parent. This
causes a problem in the UI because you can't tell them apart.
Plus, apparently, KeycloakModelUtils.findGroupByPath() will return the
first group it finds. If there is more than one group with the same
path then it might not return the group you are looking for.
It would make our code a lot simpler and less error-prone if we enforced
that all group names be unique throughout. But I don't know if that is
to restrictive for users. At the very least, two groups should probably
not have the same path.
Thoughts?
Stan
10 years
Default required actions and admin console
by Marek Posolda
Right now, when new user is registered through registration form, he is
added with all default roles, default groups and default required actions.
But when new user is created through admin console (Admin REST API) then
just default roles and default groups are added, but default required
actions are not added (More precisely, they are added but then
immediately removed at UsersResource.updateUserFromRep). This looks like
a bug to me. IMO default required actions should be added too. WDYT?
Marek
10 years
Caching of identity provider links
by Marek Posolda
Until now, we don't have support for caching of identityProvider
(social) links. So every social login or every going to "federated
identities" tab in account management needs to send DB queries. I was
looking at fixing it and I've send PR
https://github.com/keycloak/keycloak/pull/2404 . It turned to be a bit
tricky because of:
1) Caching needs to be done on both directions. For social login, you
need to lookup user by social link. But on the other hand, you also need
to look all social/identityProvider links of particular user when you go
to account management etc.
2) Because of "store token" option, the link may need to be updated in
DB quite often (in theory even during each social login).
I was thinking that storing links directly on CachedUser doesn't work
very well, because during each update of social link (which may be often
because of "store token") the user would need to be fully invalidated
from cache. Having separate cache entry for each social link also has
some downsides (many items in cache, need to have separate entry for
store the all links of user anyway). So I ended up with having the cache
entry, which contains list of all links of particular user. It needs to
be updated when any social link is added,removed or updated. This seemed
to me like good compromise. WDYT?
There are also entries for lookup user by federated identity, so you
don't need to query DB during social login.
So ATM there are not DB queries during social login or during go to
"federated identities" . I hope I handled all corner cases and
invalidations correctly, but if someone want to take look it will be
good. I don't want to add new regressions atm :-)
Marek
10 years
Should we remove links from users when identityProvider is removed?
by Marek Posolda
Currently when identity (social) provider is removed, the federated
links on linked users are not removed. It means that we may end with
user records in DB, which are linked to non-existent identity provider.
On the other hand, the advantage of current behaviour is, that when
admin user accidentally removes facebook provider and then he decides to
add it back (or just use another clientId/clientSecret or change
configuration) the facebook links of users are still alive.
So should we remove the links or rather keep as it is and not remove them?
Marek
10 years
Move email first name, last name and email to be stored as user attribute, not UserModel property?
by Vlastimil Elias
Hi,
as part of planned persistence storage SPI changes we talked about on
f2f we should probably consider removing of first name, last name and
email from UserModel property, but implement them as normal user
attributes with predefined names.
This unification should simplify few things, for example separate
mappers for attributes and properties in Clients and Identity Providers
configuration, which may be hard to understand for beginners (questions
like "what the hell is difference between user properties and
attributes?", "What user properties are available there?").
This should also simplify implementation of User profile validation SPI
we talked about on f2f meeting.
What do you think?
Vl.
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
10 years
Improved ToTP Security example
by Thomas Darimont
Hello,
the guys from projectlombok build an example application (see [0]) for ToTP
based
multi-factor authentication which showed at the Javaland 2016 conference in
Germany last week.
In this app they demoed an interesting security feature:
if a user enters a wrong ToTP code (or a far off one) they require the user
to
enter 3 consecutive valid ToTP codes - although I can imagine that this is
a bit annoying
for the user it nevertheless could add an additional level of security to
the
ToTP authentication mechanism.
They show the following message if a user entered a wrong / far-off ToTP
token:
"Due to entering a wrong TOTP confirmation code, you now need to enter 3
consecutive codes
so that we can confirm you're not just guessing codes, and detect issues
with your verification device's clock."
Perhaps keycloak could add such a feature as well.
Cheers,
Thomas
[0] - https://github.com/rzwitserloot/totp-example
10 years
Identity brokering bugs
by Raghu Prabhala
Just wanted to give a heads up that the identity brokering is not working for either saml or oidc - opened a few bugs
Kc2654 2635 2616
The identity brokering needs a lot of testing (I can do that) before KC is released as a product
Sent from my iPhone
10 years
