Btw, how's the blog post on Groups shaping up? Can you provide a
link once you post it?
Sure, I'll post the link under this thread and also in LinkedIn. Stay tuned :)
Dmitry
Regards,
Ronald
-----Original Message-----
> From: keycloak-user-bounces(a)lists.jboss.org
<keycloak-user-bounces(a)lists.jboss.org> On Behalf Of Ronald Demneri
Sent: 21.Nov.2018 10:06 AM
> To: Dmitry Telegin <dt(a)acutus.pro>; keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] group mapper per client
Dear Dmitry,
I tested your suggestion and it is working as per our needs/requirements. Many thanks for
the support, very appreciated!
Best Regards,
Ronald
-----Original Message-----
> From: Dmitry Telegin <dt(a)acutus.pro>
Sent: 19.Nov.2018 9:52 AM
> To: Ronald Demneri <ronald.demneri(a)amdtia.com>; keycloak-user(a)lists.jboss.org
Subject: Re: [keycloak-user] group mapper per client
Hello Ronald,
It has turned out there's an easy way to overcome the issue with SSO cookie, without
turning off SSO itself.
Let's imagine that your script authenticator looks like the following:
=============================================================
AuthenticationFlowError =
Java.type("org.keycloak.authentication.AuthenticationFlowError");
function invalidGroup(context) {
return context.form()
.setError("Invalid group membership", []).createLogin(); }
function authenticate(context) {
var clientId = authenticationSession.client.clientId;
var username = user ? user.username : "anonymous";
LOG.info(script.name + " trace auth for: " + username);
var groups = Java.from(user.groups)
.filter(function(group) {
return RegExp("(.*)-" + clientId + "-(.*)",
"i").test(group.name);
});
var authShouldFail = !(groups.length);
if (authShouldFail) {
var challengeResponse = invalidGroup(context)
context.failureChallenge(AuthenticationFlowError.INVALID_CREDENTIALS,
challengeResponse);
return;
}
context.success();
}
=============================================================
The idea is to wrap Keycloak's standard browser flow into a subflow, add your
authenticator after it, and make both REQUIRED (see attached image).
In this case, the authenticator will be executed unconditionally, even in the case of SSO
cookie presence (in the opposite to ALTERNATIVE). This should finally solve the problem.
Good luck,
Dmitry Telegin
CTO, Acutus s.r.o.
Keycloak Consulting and Training
Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
+42 (022) 888-30-71
E-mail: info(a)acutus.pro
On Sat, 2018-11-10 at 02:18 +0300, Dmitry Telegin wrote:
> Ronald, glad to hear it worked,
>
> There is however an important moment regarding potential security issue with your
authenticator.
>
> Imagine the following scenario:
> 1. a user with the correct group membership logs into the client app
> A; 2. the same user tries to access client B (for which he/she doesn't
> have group membership); 3. client B redirects the user to Keycloak for
> authentication; 4. due to cookie-based SSO, Keycloak decides that the user is
already authenticated and logs him/her in client B.
>
> To avoid this, you should turn off cookie-based auth for your restricted clients. Go
to Authentication, create a copy of your browser flow (which should already have your
script authenticator), remove Cookie, then go to your clients' settings and configure
Authentication Flow Overrides for browser flow.
>
> This will actually disable SSO to your clients. If this is not acceptable, there are
some other options to consider (however more complex).
>
> You should also make sure you don't enable token exchange between clients [1]
(this is disabled by default).
>
> [1]
>
https://www.keycloak.org/docs/latest/securing_apps/index.html#internal
> -token-to-internal-token-exchange
>
> Good luck,
> Dmitry Telegin
> CTO, Acutus s.r.o.
> Keycloak Consulting and Training
>
> Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> +42 (022) 888-30-71
> E-mail: info(a)acutus.pro
>
> On Wed, 2018-10-31 at 13:49 +0000, Ronald Demneri wrote:
> > Hello everyone,
> >
> > So, thankfully, after some careful reading, I managed to solve the first issue
regarding clientSession.client.clientId, which in fact shoud be
authenticationSession.client.clientId (there was a mention on using
loginSession.client.clientId in place of clientSession.client.clientId on this link
https://issues.jboss.org/browse/KEYCLOAK-4505, which I tried to use, without success).
> >
> >
> > Regards,
> > Ronald
> >
> > -----Original Message-----
> > From: Ronald Demneri
> > Sent: 30.Oct.2018 3:48 PM
> > > > > > > To: 'Dmitry Telegin' <dt(a)acutus.pro>;
> > > keycloak-user(a)lists.jboss.org
> >
> > Subject: RE: [keycloak-user] group mapper per client
> >
> > Almost forgot, If I set a static group name to compare against (which is not
our goal, but just for testing), it works correctly if the account is member of that
group. If the user is not a member, then it'll display an error like "Invalid
username or password". Is it possible to modify the response in such cases, stating
that the account is not a member of required groups, or at least have it like
"Invalid group membership".
> >
> >
> > Looking forward to hearing from you!
> >
> >
> > Regards,
> > Ronald
> >
> > -----Original Message-----
> > > From: Dmitry Telegin <dt(a)acutus.pro>
> >
> > Sent: 30.Oct.2018 4:07 AM
> > > > > > > To: Ronald Demneri
<ronald.demneri(a)amdtia.com>;
> > > keycloak-user(a)lists.jboss.org
> >
> > Subject: Re: [keycloak-user] group mapper per client
> >
> > Hello Ronald,
> >
> > If there is a literal correspondence between your AD group names and client
names (like e.g. if the client is named "foo", and the corresponding AD group is
"AD_group_foo"), you can do the following trick:
> > - make sure you have group-ldap-mapper configured in LDAP mappers,
> > i.e. AD groups are synced to Keycloak groups;
> > - create a Javascript authenticator that would check client name against
user's groups, and add it to your authentication flow. If the user tries to
authenticate against the client without being a member of the corresponding group, the
authenticator should deny login.
> >
> > If there is no such correspondence (e.g. the client is named "foo",
and the group is "AD_group_bar"), you still have the following options:
> > - map AD groups to Keycloak roles using role-ldap-mapper, then use
> > your adapter's configuration to restrict access only to the users
> > with this role (e.g. <security-constraint> in web.xml);
> > - or map AD groups to Keycloak groups, enable authorization services and use
group policy (if your client adapter supports authorization, of course).
> >
> > This, however, will need to be configured per each client, on the contrary to
the first approach (configured once per realm).
> >
> > Let me know if you need further explanations, Dmitry Telegin CTO, Acutus
s.r.o.
> > Keycloak Consulting and Training
> >
> > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic
> > +42 (022) 888-30-71
> > E-mail: info(a)acutus.pro
> >
> > On Mon, 2018-10-29 at 15:35 +0000, Ronald Demneri wrote:
> > > Hello everyone,
> > >
> > > Please forgive me if this was already asked previously. After creating the
LDAP connection (read-only) and some LDAP mappers, I am trying to figure out a way how to
allow login to clients for users in respective groups in AD, for example for client app1
allow login to users that are members of AD_group_app1; if account is not a member of the
app1 group in AD, then he should not be allowed to login. Is it also possible to do it via
role mappings? Please note that we'd like to avoid modification of AD at all costs.
> > >
> > >
> > > Thanks in advance,
> > > Ronald
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user(a)lists.jboss.org
> > >
https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user