I need to configure SAML between 2 or more applications deployed in WebLogic 10.3.6 server.
I successfully configure SAML between 2 different domains, but I need to use SAML between 2 applications in same domain, diferent managed servers. If I deploy apps in same domain, same managed server, credentials are sharing automatically even SAML not configured.
App1 call App2 within an iframe. When I access App1, logon page works. When I access App2 within iframe, credentials was transfered perfectly from App1 to App2, but when I return to App1, session is ended.
Deploying apps on diferent domains all works fine and I can access App1 and App2 normally.
I can't understand why App1's session was killed when I access App2 in same domain and different managed servers.
I don't know if it is still relevant:
The weblogic SAML2 implementation stores the JSESSIONID-Cookie under the root cookie-path "/". When your managed servers in the same domain are on the same host, the authentication cookie is overwritten each time you change your request from one server to the other. So you have to re-authenticate... (the cookie is stored only under the domain name! The application path and ports are irrelevant)
The solution ist to start each managed server under a different ip-address, dns-name or simply under a different dns-alias:
e.g. for an alias:
managedserverA.example.net points to 192.168.1.5
managedserverB.example.net points to 192.168.1.5 either
Now your Browser could store the authentication cookies under different domains:
JSESSIONID CLmYRsmZJ41TgyLJkcDQNf1!1664721840 /managedserverA.example.net
JSESSIONID q6nHRsnPNscWksZw99LBJh2!606405387 /managedserverB.example.net
Do not forgert to change the published-site-url in your SAML2 configuration to include your dns-alias for each managed server:
published site url: http://managedserverA.example.net:7020/saml2
published site url: http://managedserverB.example.net:7030/saml2
Cheers,
Tomislav Dedus
Related
I'm using oauth2-proxy with Keycloak to authenticate to applications.
Oauth2-proxy sits in the front, and when a request comes to port 4180 it redirects to Keycloak, once you authenticate it redirects to the upstream address (where the application lives)
This works well as long as the application is on the same server as oauth2-proxy.
When the application is on a different server, all the same process goes well with no errors, (exact same configuration except for the upstream which now points to another server:port), but instead of redirecting to the upstream app on the other server, it redirects to the same server:4180 and shows me an Nginx welcome page.
Could this be a configuration issue, or is it mandatory that the application is in the same server as oauth2-proxy?
I have a Website that runs on a web farm (4 servers) behind a load balancer. The load balancer is the one that has the ssl certificate for https and decides to what server the requests go to.
In the code for the website, using .net Core I have in the startup.cs file logic in the Configure method to force the https redirection with app.UseHttpsRedirection(); So when we access the site without https the .net core permanent redirect the user to the https version (this is importand bc the web app is a PWA, so we need it for use service worker)
Imagine the url to access the website is https://production.website.com, again if the user try to go to http://production.website.com, it will redirects to https version. But you can also access each server in the web farm directly using these subdomains http://prod1.website.com, http://prod2.website.com, http://prod3.website.com, http://prod4.website.com (we have this set bc we want to test individual servers in case a deployment error happens on a specific server).
The problem is, bc the ssl certificate is in the load balancer (production.website.com domain), when you try to go directly to a individual server (prod1, prod2, prod3 or prod4) the .net core will redirect it to the https version and that server doesnt have a ssl certificate and the user will see an error on the browser, so we need a way to control that with a condition. So what the problem is? that at the startup.cs code we dont have access to the site url bc we dont have a request yet, I have research a lot and some workarounds that use to work in the past now with .net core 3.1 dont.
So how I can make that the code in the configure method doesnt force a https redirect if the users is accessing the individual servers and not the main domain for the web site?
I am running Keycloak on an OpenShift project, and I have 4 pods running:
keycloak (v8.0.1 configured to listen on 8443 with TLS),
keycloakdb (PostgreSQL DB),
proxy (Apache 2.4 reverse proxy), and
portal (our app that we developed to handle connecting to other applications).
The keycloak pod also contains two jar files that we “borrowed” that implements PKI authentication as part of the log on.
The routes configured in OpenShift are
apache: tcp/443 to tcp/8443 on the apache pod
keycloak: tcp/443 to tcp/8443 on the keycloak pod, and
Current state:
A connection to https://proxy.domain.com is redirected to https://keycloak.domain.com for authentication
https://keycloak/domain.com which requests my certificate for a 2-way TLS authentication
then redirected to https://keycloak.domain.com/auth/auth?response_type=code&scope=openid&client=potal&state=&redirect_uri=https://proxy.domain.com/redirect_uri&nonce=
The browser displays a page which give details of my certificate and my user account name with a button to continue
Clicking the continue button, POSTs to https://keycloak.domain.com
The browser is then redirected to https://proxy.domain.com:8443
Since there is no route to https://proxy.domain.com:8443 the connection times out.
The question is how do I get keycloak to redirect the browser to https://proxy.domain.com on tcp/443?
For redirecting to particular URL after authentication, you can use URL redirection setting in client settings.
The problem is the redirect_uri in the authentication request. It points to proxy.domain.com instead to the portal.
The redirect_uriis set by the OAuth 2.0 client code in the portal. Probably, the portal software thinks its own URL starts with proxy.domain.com.
So investigate and fix the OAuth 2.0 code in the portal (probably just a configuration issue).
We have a couple of back-end web applications to which we want to provide access via the public internet. To that end, we are setting up a reverse proxy (IIS 7.5) from our DMZ. At the same time, we want these web applications to be claims-enabled through ADFS 2.0.
WEB1.MYCORP.COM/WFE1 is the other back-end web application, on our internal network
WEB1.MYCORP.COM/WFE2 is the other back-end web application, on our internal network
ADFS.MYCORP.COM is the ADFS 2.0 server, on our internal network
FSPROXY.MYCORP.COM is the ADFS 2.0 proxy server, on our DMZ
RPROXY1.MYCORP.COM is the reverse proxy for WFE1, on our DMZ
RPROXY2.MYCORP.COM is the reverse proxy for WFE2, on our DMZ
In keeping with the proper configuration of ADFS, our internal DNS resolves ADFS.MYCORP.COM to the actual internal server, while external DNS points ADFS.MYCORP.COM to the ADFS proxy (FSPROXY).
So, here's the scenario:
End user browses to RPROXY.MYCORP.COM
Reverse proxy forwards request to WEB1.MYCORP.COM/WFE1
WFE1 redirects browser to ADFS.MYCORP.COM (actually FSPROXY)
ADFS Proxy prompts for credentials and authenticates against ADFS server
Upon successful authentication, browser redirected back to web app
I have a couple of questions. Do I need to configure something in the rp or the application to allow this. Also the adfs endpoint is the rp url is that an issue?
Do I need to set up something for the reverse proxy as well? (Should I/can I) set up a claims-enabled reverse proxy in IIS? How do I set up the reverse proxy rules to pass back the ADFS request unaltered? Currently, when I try to access the back-end application, it fails with a 401 authentication error. If I remove the proxy and just hit the app server it works fine.
Further,
This fails:
The path is client --> rp -->app -->adfs --> rp -->app --> rp -->client machine
this works:
The path is client -->rp -->app -->adfs -->app -->rp -->client machine
Any suggestions would be greatly appreciated!
Not familiar with how you enabled reverse proxy in IIS (ARR?). Something like this http://blogs.iis.net/carlosag/setting-up-a-reverse-proxy-using-iis-url-rewrite-and-arr
One choice for you is to use ADFS 2012R2 (if possible) because the proxy in that, the Web Application Proxy, handles both ADFS authentication and can handle app publishing for your claims enabled application. There are 2 ways you can publish your app to the internet. Once is pass-through which is kinda what you are trying to do. But it also allows pre-authentication support for a claims aware app. This way, you can have a different policy that decides whether the application can get pass your EDGE network before a packet goes to your internal application.
After doing lots of digging and fiddler traces I found the issue. In testing idp setup the token was different then stage env. The fiddler traces showed that the token was making it back to the app server. The issue was it also looked like the cookie dropped off for no reason. The issue was because the old dev ipd value disagreed with the stage value...naturally. Once I cleared the old token from the database everything worked.
I am trying to implement third party authentication with openAM, and have a doubt regarding openAm implementation, i.e if my application is distributed under different servers which are geographically separated and controlled under the same DNS name. How can I differentiate the sessions of different server. Say for example if I type www.google.com it can forward to any of the nearest server available, now if I have to authenticate google.com how will my openAm know that the request is for that particular server. If I ask it in other way, so whenever we are changing a policy in openam or invalidating a session it callbacks to all the registered server, now in distributed environment how it can differentiate the server IP's
I assume you have some sort of LB in front of you servers. I would suggest creating a sticky session at the LB, like a cookie saying what server the user is on before starting the authentication. Then when authentication i done, openam redirects back to your LB and the LB directs to the correct server.