Supporting multiple front-end channels (KEYCLOAK-6073)
by Luke McDougall
Hi... I'd like to continue a discussion regarding supporting multiple
public realm URLs that was started on
https://issues.jboss.org/browse/KEYCLOAK-6073.
We are using Keycloak to support single-sign on to our suite of products.
Our products run in a Kubernetes cluster; we deploy a Kubernetes cluster
into our customers data centers to host our products. The products consist
of microservices built on Widlfy, NGINX, Spring Boot, and others. We use
NGINX ingress controllers as the entry point into the cluster.
Users may access the products through multiple DNS names and/or IP
addresses; this is driven by each customers requirements. For example,
regular customer employees may access the cluster using a loadbalancer DNS
name while external contractors may need to connect via a VPN and are
required to use a different DNS name (maybe to a different loadbalancer).
In other cases multiple IP (or VIP) addresses are used. All users are
logging into the same Keycloak realm.
The result is that the 'issuer' in the JWT tokens is different depending on
how the user is required to access the cluster; we need the Keycloak
adapter in our backend services to accept each of these possible issuers.
We have developed proof-of-concept changes in the Keycloak adapter to solve
this by allowing us to specify a list of valid realm URLs in the
keycloak.json file used by the adapter. Our intent was to submit this as a
pull request for KEYCLOAK-6073. However at the same time as we were
working on this, someone else submitted a pull request against
KEYCLOAK-6073 to support a single frontend and a single backend URL.
I commented on the JIRA issue asking whether we could enhance this PR allow
multiple frontend channels. I'm concerned that if this PR is merged
without supporting multiple frontend channels that it will be more
difficult to add this afterwards. However at Stian Thorgersen's request I
have moved the conversation off JIRA and onto the mailing list.
What do you think? Is there any reason Keycloak shouldn't support multiple
frontend channels? We have customers that are very strict about separating
client access as described above, and I'm not sure how else we could
support this with Keycloak.
Thanks...
Luke
4 years, 9 months
Can't get results from IterablePermissionEvaluator
by Perot Francis
Hi,
While debugging my Keycloak SPI, I think I found a bug.
When calling IterablePermissionEvaluator.evaluate(...), I can see that permissions and policyEvaluator are used to update a decision with different results (field Map<ResourcePermission, Result> results in AbstractDecisionCollector) then a call to decision.onComplete() should validate found results.
In fact, decision.onComplete() is a method from AbstractDecisionCollector which calls onComplete(Collection<Result> permissions) but this one is empty in AbstractDecisionCollector and is not overridden in DecisionPermissionCollector which is the actual instanciated class in IterablePermissionEvaluator.
Finally, when calling decision.results() in IterablePermissionEvaluator.evaluate(...), the result will always be empty.
I think that AbstractDecisionCollector (or DecisionPermissionCollector) should be defined with :
protected void onComplete(Collection<Result> permissions) {
permissions.forEach(this::onComplete);
}
Or maybe I missed something ?
Thanks,
Francis
4 years, 9 months
Fwd: Social login rest api
by Yor Men
Hi
I have One issue, when ever user authenticates the redirect get a # infront
rather than a ? at the end
It redirects to something is http://localhost:1021/me-details#session_state.
And it seems sessio is created for the user in keycloak. I checked from the
admin console session management.
Any idea why this is happening??
I really appreciate your concern.
4 years, 9 months
[KEYCLOAK-10022] Regarding the fix to the bug "few Admin events not getting raised"
by Shiva Prasad Thagadur Prakash
Hi Guys,
Feedback welcomed.
I have tried fixing the bug with ID "KEYCLOAK-10022" (https://issues.jb
oss.org/browse/KEYCLOAK-10022). It was due to a wrong flag being
checked to decide whether the admin events has to be raised or not.
For example, in file PolicyResourceService.java at line number 260, the
flag "authorization.getRealm().isAdminEventsEnabled()" is being checked
before raising the admin event. Actually, this flag is used to identify
whether the admin events are to be saved or not saved and not to
identify whether admin events are to be raised or not raised.
The fix is to remove the if condition that checks for this flag before
raising the admin events. The same fix applies in few other
files: PolicyService.java, ResourceSetService.java and
ScopeService.java. I have verified the fix and after the fix I am able
to see the missing admin events.
Do you guys agree with the proposed fix? Can I raise a pull request?
Eagerly waiting to hear from you.
Thanks & regards,
Shiva
4 years, 9 months
Re: [keycloak-dev] UMA authorization process in Gatekeeper
by Maxime Suret
Hi Bruno,
My plan was to keep policy enforcement in resource servers, Gatekeeper
being only responsible for turning permission tickets into RPTs as
described in [1].
The reasoning behind this is that is not always possible to deduce
resource names and scopes only from HTTP paths and methods. This works
well with REST services but not so much with other kinds of APIs such
as GraphQL which uses a single endpoint.
Does that look reasonable to you ?
[1]
https://github.com/keycloak/keycloak-documentation/blob/5e4b5a2be332d4012...
On Fri, 2019-06-28 at 15:35 -0300, Bruno Oliveira wrote:
> Hi Maxime, we will be glad to review new contributions to Gatekeeper.
> Although, we need to work together to limit the scope of KEYCLOAK-
> 7502[1].
>
> My suggestion is to start the discussion on the dev mailing list with
> your
> plans around this, so we can reach an agreement and add all the
> details to
> that Jira. Initially, the scope should be limited to what Pedro
> already
> did for the Node.js adapter[2][3][4].
>
> Does it make sense?
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-7502
> [2] - https://issues.jboss.org/browse/KEYCLOAK-3334
> [3] -
> https://github.com/keycloak/keycloak-documentation/pull/654/files
> [4] - https://github.com/keycloak/keycloak-nodejs-connect/pull/142
>
> On 2019-06-28, Pedro Igor Silva wrote:
> > Thanks, Maxime. I'm adding Bruno to see what he thinks about it.
> >
> > On Fri, Jun 28, 2019 at 11:25 AM Maxime Suret <
> > maxime.suret(a)early-birds.io>
> > wrote:
> >
> > > Hi Pedro,
> > >
> > > Yes the goal is to make client developement easier and faster by
> > > moving
> > > all UMA logic inside Gatekeeper.
> > > Handling UMA workflows in web applications would require clients
> > > to
> > > access and modify Gatekeeper's cookies which is quite ugly.
> > > This could indeed be a done as part of the feature request you
> > > mentioned, even if permission policies would still be enforced by
> > > the
> > > resource server and not Gatekeeper itself with this solution.
> > > If that's ok for you I will go ahead and open a PR referencing
> > > this
> > > JIRA ticket.
> > >
> > > Thanks & Best Regards,
> > >
> > > Maxime
> > >
> > >
> > > On Thu, 2019-06-27 at 10:14 -0300, Pedro Igor Silva wrote:
> > > > Hi Maxime,
> > > >
> > > > Interesting idea. Basically, the GK will do the dirty work for
> > > > clients, right?
> > > >
> > > > We could probably consider having this task as a subtask of
> > > > https://issues.jboss.org/browse/KEYCLOAK-10367 ?
> > > >
> > > > Regards.
> > > > Pedro Igor
> > > >
> > > > On Wed, Jun 26, 2019 at 2:05 PM <maxime.suret(a)early-birds.io>
> > > > wrote:
> > > > > Hi All,
> > > > >
> > > > > When Keycloak Gatekeeper gets a 401 response with a
> > > > > permission
> > > > > ticket
> > > > > from upstream, it would be very useful if it could fetch the
> > > > > corresponding RPT and retry accessing the upstream resource
> > > > > with
> > > > > it.
> > > > > The RPT would then be placed in the access cookie to avoid
> > > > > this
> > > > > process
> > > > > in subsequent requests.
> > > > > That would also be a nice feature to have when using
> > > > > gatekeeper as
> > > > > a
> > > > > forwad signing proxy.
> > > > > What do you think ? I am willing to implement this myself.
> > > > >
> > > > > Thanks !
> > > > >
> > > > > Maxime
> > > > >
> > > > >
> > >
> > > --
> > >
> > > <
> > > https://www.eventbrite.com/e/atelier-by-early-birds-x-saint-gobain-distri...
--
<https://www.eventbrite.com/e/atelier-by-early-birds-x-saint-gobain-distri...>
4 years, 10 months
Social login rest api
by Yor Men
Hi,
Does keycloak provide an api that can generate a link for you to click on
and redirect you to let say github and login.
Let me sight an example, we have an application that is secured with
keycloak, we want to allow users to be able to login to the app using
github, facebook and google without having to go to the keycloak page in
any way.
What we want to do is, when the login page is called, the controller
generates the URI and is bound to the model. This model value is placed in
a particular social login button.
Any other suggestion is welcome.
Thank you.
4 years, 10 months
Make AuthenticationSessionModel available through KeycloakContext in KeycloakSession?
by Vlastimil Elias
Hi,
as I described in [1] , we have a problem that
AuthenticationSessionModel is not available in EventListenerProvider SPI
and we need it there (we have to use dirty hacks now to workaround this
problem, and we are not able to workaround it in all cases still).
I discussed this with Marek Posolda, and a viable solution seems to be
to make current AuthenticationSessionModel available through
KeycloakContext in KeycloakSession in a same way as current RealmModel
and few other objects. This way it will be automatically available in
all SPI's without need to update each of them (it may be null if SPI is
called out of AuthenticationSession context naturally, so SPI
implementer have to check it correctly).
Dos anybody have any obligation against this proposal, or better proposal?
If not, the I can try to prepare and provide PR against Keycloak master.
It is really important for us to make this problem resolved, but I can't
afford to waste my time by PR which will not be accepted at the end.
Thanks for any reaction
Vlastimil
[1] https://issues.jboss.org/browse/KEYCLOAK-10209
--
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat
4 years, 10 months
"You are already logged-in" issue
by Vlasta Ramik
Hi,
I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if
message "You are already logged-in" can be avoided during authentication.
In current state we discard the RootAuthenticationSession when user
successfully finishes the authentication. In that moment we loose all
the information stored in AuthenticationSession(s) for other tab(s) and
in some cases we do not know where to redirect the user. To solve this
issue there seems to be 2 possibilities.
1. Do not remove RootAuthenticationSession once the user finishes the
authentication. Instead we can remove just AuthenticationSession
associated with the specific tab from the RootAuthenticationSession and
the RootAuthenticationSession would be deleted together with last
AuthenticationSession from it.
2. Add and pass redirect_uri parameter to login flow. With the parameter
we'd always have an information where it should be redirected in case
the authentication was successfully finished in other tab.
With solution #1 it'd increase the memory as it keeps
RootAuthenticationSession alive till all tabs are alive.
Solution #2 keeps current behavior regarding the authentication sessions
but it slightly increases the length of uris.
wdyt?
4 years, 10 months
