I have been scratching my head for days on this issue so thought I would try and seek some help here.
So I have a Wildfly server and an external keycloak server used for autentication.
My keycloak server uses OICD and a public client.
Usually the flow works fine, the user logs in, and subsequent resources authenticate properly with Keycloak. However the issue comes when I deploy my custom plugins to my wildfly server. Each plugin needs to authenticate to the keycloak server, usually this happens without issue on the first request. However some of my plugins are REST only, so their first request is an XHR request and this request fails as it gets redirected to the login page of keycloak which it does not understand. I am unsure how this flow is meant to work like.
If I set my XHR request withCredentials to true, it triggers CORS on my keycloak server, which is fine I have that setup correctly, however what is baffling to me is that the return request from keycloak then triggers CORS on my wildfly server, and because Keycloak redirects uses a no-refferer policy the origin is null! Setting my wildfly server to accepting null would not be acceptable.
I preferably would want a solution where each plugin would not need to authenticate towards my keycloak if the user has already done the login process but I cannot find any way of enabling session sharing between deployed plugins.
Related
I have a fastify server that serves cookies to maintain the session.
When I test on localhost, it works as expected. I get a cookie on localhost:3000.
When I host my server as a container image through Cloud Run, however, I can not see any cookies inside the route. I can see the request has a cookie when it's sent to the server, but it's not being parsed. This is causing my session to create a new session and I can't get any context.
Are there any special considerations regarding Cloud Run and cookies?
Only If you are using Firebase Hosting + Cloud Run, __session is the only cookie you can store, by design.
This is necessary for Google to be able to efficiently cache content on the CDN -- Google strips all cookies from the request other than __session.
This is documented here.
If you are using Load Balancer, or other means like custom domains to connect to your Cloud Run service, there is no restriction on cookies, and you get all.
I currently have the following architecture
APP -> API -> KeyCloak
I want the APP to be able to send requests to my API which will then internally proxy certain requests to KeyCloak. For example, I'd like to make a request to the /userinfo endpoint in KeyCloak through my API. If I can figure this out I can then perform more complex features.
APP -> http://api:port/api/userinfo
API -> http://keycloak:port/auth/realms/quartech/protocol/openid-connect/userinfo
I have a valid JWT Bearer token. As I can directly make the request to KeyCloak successfully, however if I attempt to make the request via my API it returns 401. Even though it is using the same JWT Bearer token.
I believe it has something to do with configuring the KeyCloak client to allow requests to come from the API. But so far I haven't been able to figure it out.
I've discovered it required a DNS entry to local development within a Docker container.
I've edited the hosts file and added a 127.0.0.1 keycloak and then al
My project is serverless, the user will log in using the hosted sign in UI from cognito, we are only using the implicit grant in our oauth flow, the ui redirects the browser after login being successful but i am concerned about the user's data for being potentially leaked, i know the redirection hash does not contain a refresh token but still there could be a chance that within the token's lifespan it could be expose somehow.
so i was wondering if there is a way to verify with a simple true or false if the user is still logged in with cognito.. we are not making use of any SDK and we don't intend to use them.
if that is not possible then is it possible to change the response scope for /userInfo response to only show few fields?.. to show only email and password
In the end i did not work with implicit grant oath flow for my project, i am now using ELB for handling the cognito's session in the back-end and keep the data only for the server side.
So basically i have a rule in ELB for my project that triggers authentication when a path is accesed, the console for ELB makes it easy to configure and it creates a client session cookie when the authentication is success, this way the Load Balancer can have an easy track of the client that is making the request to a protected route by cognito. Once the authentication is success the Load Balancer sends the authentication data as request headers to the server and from there it is easy to validate and decode the required user data.
I'm trying to write a small bitbucket plugin that enables SAML 2 SSO authentication.
I've been looking at the source code of sample authentication plugins in bitbucket, and it looks quite straightforward.
However, my question is what is the best approach to handle authentication that spans over separate requests.
To do SAML SSO, you have to send a POST to the IdP via the user's browser, and then it sends a SAML token back via POST's again, but then you're no longer in the middle of authentication. So I'm trying to figure out the cleanest way to kickstart the authentication process again, my current thought is as follows:
Have my authentication handler that implements com.atlassian.bitbucket.auth.HttpAuthenticationHandler do a check to see if SAML authentication has happened in the authenticate() method, and then redirect them to the IdP if necessary. (Authentication process has stopped because of the redirect)
Receive the SAML token from the IdP on a separate servlet and check SAML token is good to use. Presuming it's all good, set a servlet request attribute (or session attribute) with the username that has been validated, and then forward the user to the original page they tried to access. This should start the authentication process again.
My authentication handler runs again, checks for the request/session attribute, and this time creates the ApplicationUser that is necessary for authenticate() to complete successfully.
Does this sound like a good approach? I had a look at the bitbucket source code for how the Crowd SSO handler works, but with Crowd SSO it doesn't need to redirect you an external login page, so it doesn't have an example of this flow.
Ideas?
I'm building an Angular app with an API backend. On a combination of pieces of advice, I built the API with a flavor of token authentication. The flow is roughly as follows:
POST to login endpoint with credentials
Validate credentials and authorization, then generate a new token
Return token to client
Client uses token via HTTP Basic to access API resources
This is all working well. The problem arises in creating a session based on this token. I don't believe I should simply hold the token on the client in a cookie, but I do need a session to persist between page refreshes, etc. My Angular app is stateless and completely populated via API calls.
I'm looking for a recommendation as to hanging on to this token on the client. I feel there's danger in holding the token in a cookie because the cookie could be stolen and simply used to authenticate as someone else, but perhaps this is incorrect.
Thanks in advance for your assistance!
The only known way for me to identify a user is to use some token on the client.
HTTP is stateless and can't know which request is coming from which user (browser). You can't identify the user by his ip address (many users are behind a router and share a connection). You could try browser fingerprinting, it can work on some browsers but not on all.
I would recommend using a cookie to store this token on the client.
They are send to the server on every request and you can do some protection to keep them from getting stolen.
To protect this cookie from man in the middle attacks you need to use an encrypted connection over HTTPS to the server.
Set the following attributes on the cookie:
HTTPOnly: cookie can't be accessed by javascript (XSS protection)
Secure: cookie will only be send over https
Path: cookie will only be send on specified path e.g. /login
I would also define an expiration date on the cookie, so the cookie is invalid in like 2 days or something.
But you are right. If this token gets stolen someone else can login as this user.
Since its an Angular app, I'd assume all authenticated methods will only be served to ajax requests (you can tell your server to only respond to ajax) in which case CORS will help you.
The only way to be completely secure is HTTPS, however this method is probably more secure than you think. Read up on CORS a bit for more info, but essentially the idea is that servers will only respond to ajax requests coming from html pages that were served by that same domain.
Pre-flight OPTIONS requests are often sent to verify this. The browser sends an OPTIONS request with an Origin header (the origin of the page) before the actual request. If the origin matches the domain of the server receiving it, the subsequent request is allowed. Otherwise, it violates the Same Origin Policy and will be rejected.
This prevents someone from sniffing out the token and sending a request with the token from a page that your server didn't serve (like something running on the hackers local machine).
If you are doing credit card transactions or anything super secure, you should use HTTPS though.
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing