We are running jenkins and few other tools behind nginx ingress and we have handled the user authentication through this as well.
Once the user logs in to our app, the credentials get stored in nginx ingress and it is passed to jenkins as cookies.
Hence once user gets redirected to jenkins from our app, he would be logged into jenkins automatically.
Now we are trying to replace nginx ingress with istio ingress. We have placed our application behind istio ingress and are using the OIDC provider-keycloak along with authservice for authentication.
We are able to get the user to login to our app. But we are trying to figure out a way in which we can pass these credentials onto jenkins using cookies or through any other means.
Can someone let us know a way in which this can be achieved?
Related
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.
I have an emissary ingress gateway and I want to authenticate requests with my keycloak server. I see that the integration is available with Edge Stask but, there is an alternative solution ready to use to solve the auth problem? thanks.
Emissary ingress has a feature called authservice. This allows you to create the authservice kind and point it to a backend service to handle authentication.
When using keycloak you can use openIDConnect from your authservice backend to authenticate users to keycloak.
https://www.getambassador.io/docs/emissary/latest/topics/running/services/auth-service/
I am using Keycloak to authenticate a Vue app that is running on Docker. Currently, my configuration includes using grant_type=password along with client-id and client-secret to authenticate a client.
Because I want to make client-secret configurable, what is the best way to use keycloak client-secret in docker-compose.
I have two Angular applications on two separate domains that use AWS Amplify for authentication.
They both use the same Cognito user pool and the same Cognito app client.
The app client does not use the Cognito hosted UI and does not use OAuth 2.0.
The authentication protocol is the default AWS Amplify one: SRP (Secure Remote Password protocol).
Sometimes my users log in to domain1 when in fact they should be logging in to domain2 (business rule, depends on the user's profile).
In such cases, I would like them to be redirected to domain2 and be automatically authenticated.
Is there a clean way to do such a redirection with Cognito?
I have a solution which implies passing Cognito tokens from domain1 local storage to the redirect url, and then doing the opposite in domain2, but clearly this feels like a hack.
I've setup apache reverse proxy for my application with ldap authentication.
The problem is that the backend application also requires authentication.
After I entered ldap credentials, it always returns 401 and doesn't prompt for the application authentication.
The backend uses different credentials.
Assuming that the backend-server uses the very same LDAP authentication as the frontend you might want to have a look env var proxy-chain-auth in docs for mod_proxy_http.