1:49 p.m.
The nodejs-connect adapter's middleware() function includes automatic setup
of a logout route which redirects to the keycloak server to logout the
authenticated user. The relative path to the logout route is customizable
via the options object, but there is no specified way to opt out of the
logout route. Looking at logout.js in the source I can see that passing
something which will never resolve as equal to request.url would result in
the logout route always being skipped, which is workable but is a hack.
I'm looking at using this for a backend service which will not do user
login/logout management at all but will only be doing checks for
authorization details. I don't see a need for logout functionality on such
a service. I can see three possibilities:
1) I'm looking at this the wrong way, and I actually do want logout
functionality for some reason.
2) I'm looking at it the right way, and the aforementioned hack is the
"normal" way to do it, but undocumented.
3) There's a feature request hiding here for a config option on
middleware() to opt out of the logout middleware.
(3) seems most plausible to me at this point but I don't want to jump into
feature request mode with an incomplete understanding of the situation. Any
opinions?
5:52 a.m.
Hi Jonathan, I believe what you're looking for is for one of
keycloak-connect dependecies
https://github.com/keycloak/keycloak-nodejs-auth-utils which contains only
authorization. On keycloak-connect authorization and authentication are
tied together.
If that's not enough, please file a Jira.
On Thu, Apr 6, 2017 at 5:04 PM Jonathan Little <rationull(a)gmail.com> wrote:
The nodejs-connect adapter's middleware() function includes
automatic setup
of a logout route which redirects to the keycloak server to logout the
authenticated user. The relative path to the logout route is customizable
via the options object, but there is no specified way to opt out of the
logout route. Looking at logout.js in the source I can see that passing
something which will never resolve as equal to request.url would result in
the logout route always being skipped, which is workable but is a hack.
I'm looking at using this for a backend service which will not do user
login/logout management at all but will only be doing checks for
authorization details. I don't see a need for logout functionality on such
a service. I can see three possibilities:
1) I'm looking at this the wrong way, and I actually do want logout
functionality for some reason.
2) I'm looking at it the right way, and the aforementioned hack is the
"normal" way to do it, but undocumented.
3) There's a feature request hiding here for a config option on
middleware() to opt out of the logout middleware.
(3) seems most plausible to me at this point but I don't want to jump into
feature request mode with an incomplete understanding of the situation. Any
opinions?
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
1:50 a.m.
I did look at the auth-utils package and it looks like I could use the
Token module in that package, with my own code to pull the token content
out of the request and my own middleware check validating against the
token, but I was hoping to use keycloak-connect's middleware to handle all
interactions with the token. I'm sure I could use some of the other
available JWT middleware as well but since we're using keycloak for our
auth backend and in our web frontend I figured it'd be simplest to use it
on our service backend as well. And the keycloak-connect middleware is
really convenient to use.
Is the recommended way to go to provide custom middleware or find other
(non keycloak) middleware to deal with parsing tokens etc. when securing a
service backend with bearer tokens?
I'm happy to file an issue covering disabling logout and could possibly
submit a PR too but I don't want to push in the wrong direction, and I
realize it's possible there are other things the library is doing as well
that I don't know about yet that are specific to a service that actually
needs to log in and out.
On Fri, Apr 7, 2017 at 3:52 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Hi Jonathan, I believe what you're looking for is for one of
keycloak-connect dependecies https://github.com/keycloak/keycloak-nodejs-
auth-utils which contains only authorization. On keycloak-connect
authorization and authentication are tied together.
If that's not enough, please file a Jira.
On Thu, Apr 6, 2017 at 5:04 PM Jonathan Little <rationull(a)gmail.com>
wrote:
> The nodejs-connect adapter's middleware() function includes automatic
> setup
> of a logout route which redirects to the keycloak server to logout the
> authenticated user. The relative path to the logout route is customizable
> via the options object, but there is no specified way to opt out of the
> logout route. Looking at logout.js in the source I can see that passing
> something which will never resolve as equal to request.url would result in
> the logout route always being skipped, which is workable but is a hack.
>
> I'm looking at using this for a backend service which will not do user
> login/logout management at all but will only be doing checks for
> authorization details. I don't see a need for logout functionality on such
> a service. I can see three possibilities:
>
> 1) I'm looking at this the wrong way, and I actually do want logout
> functionality for some reason.
> 2) I'm looking at it the right way, and the aforementioned hack is the
> "normal" way to do it, but undocumented.
> 3) There's a feature request hiding here for a config option on
> middleware() to opt out of the logout middleware.
>
> (3) seems most plausible to me at this point but I don't want to jump into
> feature request mode with an incomplete understanding of the situation.
> Any
> opinions?
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
2589
days inactive
2591
days old
2 comments
2 participants
participants (2)
-
Bruno Oliveira -
Jonathan Little