We are using keycloak as auth server. We have jetty as app server which has keycloak configured as auth resource server (using keycloak adapter).
We have java client desktop applications which connect to jetty for REST calls. Whenever client app starts, it asks for login (using KeycloakInstalled Java plugin). It gets the token and passes it in every subsequent requests to Jetty. This whole flow works smoothly with no issue.
Now, when I check Jetty http logs, I see one call to KC server for every incoming call to Jetty. This call is /auth/realms/{realm_name}/protocol/openid-connect/token
As I increase the load on Jetty server, above KC call starts failing with below error:
org.apache.http.NoHttpResponseException: <jetty_url> failed to respond
java.lang.RuntimeException: Failed to enforce policy decisions.
Due to this every call becomes unresponsive and system goes down.
Now I have few questions:
1) Why KC adapter is firing above call to KC on every request? Is there setting that KC adapter can cache
the result for some time.
2) I believe above exception is some issue in httpclient which KC adapter uses internally. Is there something that we can change here?
3) Whenever I fire rest call from browser (which internally redirects to KC and asks for login), the above KC /token call never happens. The difference between desktop client vs browser request is that browser sets cookie which has JSESSIONID and session_state. Should our desktop client also use JSESSIONID instead of token? what is the correct way? If yes, how to get the JSESSIONID. I could get the session_state from token.
Please help.
Related
I was trying out the curity configuration for an authentication service and a token service for OAuth and OpenID Connect locally. After all the configuration, when I was trying to test it with OAuth Assistant, I get an error:
Bad request
The request could not be processed
In the terminal, I can see these two INFO logs for particular
se.curity.identityserver.util.AllowedFrameOriginUtils - Requested origin is not allowed: 'http://localhost:...'
se.curity.identityserver.controllers.authorize.AuthorizeOAuthRequestModelProvider - Could not establish the redirect uri for request and client www. If this error occurs *after* being redirected to the authentication service and back, then this error has probably occurred because the original session cookie has been lost. Ensure that the cookie named 'sessionid' was sent to the authentication service. If not, check that the user's browser is not withholding it (for example by the cookie jar becoming full) and that a reverse proxy is not interfering with it.
There is no issue with sessionid. Anyone know how to fix this issue?
I have a relatively simple setup where I am using stomp over websockets to retrieve data from my backend to avoid resetting the session timeout. I am running into an issue that mostly happens when I restart my server. I reboot and I am properly prompted to login. After the login succeeds I am redirected. However instead of being redirected to the page I requested I am redirected to the stomp endpoint.
I suspect this is a timing issue where the stomp client is continuing to connect to the initial stomp http endpoint after the server starts up and is overwriting the request to the page with a request to the stomp endpoint.
Is there some way to make the stomp endpoint not a valid target for a login redirect?
This seems like it is really only an issue during dev since it really only occurs when the server is restarted. However, with my dev environment being deployed on push I dont want the testers to report this as an issue.
I have a web application which currently uses lighttpd with mod_auth and the htdigest method for authentication. I want to expand the web apps functionality to allow for 2FA. If I understand correctly, what happens for htdigest authentication is the following:
The browser requests a website from the server
The server responds with "authentication required"
The browser shows the user a window asking for username/password and sends this information to the server
The server serves the webpage
If I understand correctly, the server caches this auth info and automatically sends it for following requests.
Now, I want to add 2FA. I found out that I can use fastcgi to build a custom authorizer. Can I use this to do 2FA? How can I ask the browser to provide the user with a possibility to enter the OTP? It's no use to cache the OTP and send it with every request, so I guess I need to store a session token or something which the browser should send with every following request?
I have a number of web api services created that need to get the authenticated user.
I have gotten the id server v3 working such that I can enter /core and /connect/token and my client gets a token and is passing it back to the server.
single iis server running all of the web app and web services and id server.
when I add the token authentication package I am getting an error that the well known configuration can not be found.
I am looking for what I need to change to make this work so that api calls get an authenticated identity.
I think this is a startup problem but I have my app.map() first and then the app.UseIdentityServerBearerTokenAuthentication() after.
so do I make it wait fro the first to complete ? async ? await ?
ok I am slow, I found an option to delay load the metadata and that fixed that.
now the api calls show that the user is authenticated.
Any way to test OAuth integration to google without having to have a port forwarding rule in my router back to my development Mac?
Background:
Developing Ruby on Rails web app that will request data from Google Calendar API via OAuth
Using Rails "OAuth Plugin" for this purpose
Developing on MacBook which is running my dev environment
Google needs (as part of OAuth) to make a callback back to my local dev environment
Can't seem to think of a way to test with Google without having to set a Port forwarding rule in my site's router back to my Macbook?
This threw me for a loop too. I actually went through the work of setting it up on a public IP even though I didn't have to in the end.
But yes, your comment is correct. The callback URL is passed on to Google during the redirect then after you've been authenticated with Google, Google will redirect you back to the callback URL providing an authorization code as a parameter.
The only server to server communication that happens is exchanging the authorization code for access and refresh tokens. This typically happens on the callback page. But since it's initiated by your server and not Google, no special open ports are required.