Our application is protected with OpenAM web agent. We are encountering a situation where after the OpenAM is sending a post request with HTTP_REMOTELOGIN and Set cookie.But as response Iplanetdirectorypro cookie is getting expired. The issue came when the domain of our web site got changed from a.x--> a.y. Things are working perfectly for old URL domain.
Same configuration for the new domain is working on pre production and when the changes where done to Production, the web page after authentication from SSO is not properly loading due to the fact the OpenAM cookie is getting expired.
In the browser we can see the warning as "A cookie associated with a cross-site resource was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032."
The issue is persisting on all web browsers.
We tried various things in IIS such as enabling CORS, disabling secure cookie setting but we had no luck.
So the question is whether OpenAM cookie managed somewhere in IIS which needs to be configured specific to the new domain.
Can anyone help !
Related
I have next components:
RP-1 (connected by Ws-Fed, WIF)
RP-2 (connected by SAML, Federation Provider, actially it is another ADFS)
MY-ADFS (ADFS Server 2019 as primary STS)
MY-IP (separate Identity Provider web service, Identity Server 4)
Thus, when I make a sing-out request from RP-1(Ws-Fed), a simple Ws-Fed Logout is formed a request to ADFS:
GET https:/MY-ADFS/adfs/ls/
wtrealm: https://RP-1.com/
wa: wsignout1.0
wreply: https://RP-1.com/logout/
Next ADFS makes redirect to IP:
GET https://MY-IP/WsFederation
wa: wsignout1.0
wreply: https://MY-ADFS/adfs/ls/?redirectContextId=2dd581d2-6e02-4476-915b-a581e3c855d4
thus the user clears the session from ADFS and from IP. - as expected.
However, if before the logout, the transition to SAML RP was made and the SAML session became active, then upon exiting ADFS gives an error:
MSIS7055: Not all SAML session participants logged out properly. It is
recommended to close your browser.
To fix it, I configured the logout endpoint (URL) in the SAML relying party trust as:
https:/RP-2/adfs/ls/?wa=wsignout1.0
With POST binding. After these changes, the error disappeared. But now ADFS no longer does make Logout redirec to to IP, but instead it does a SAML Logout redirect to RP-2:
POST https://RP-2/adfs/ls/?wa=wsignout1.0
SAMLRequest: PHNhbWxwOkxvZ291dFJl
And as a result, Instead of switching to IP, I remain on the RP-2(ADFS also) page where it is written that the exit was successful. However, the user still has an active session (cookies) on the IP side.
Several questions here:
It is not clear why ADFS changes the chain of calls with the SAML active session.
It is not clear how to exclude SAML Logout redirects, or force ADFS to make Logout to IP also.
You will have to add the logout URL in the IP (Identity provider) side as well to ensure that the SAML token generated by signing out from the SaaS application through ADFS is forwarded to the Identity provider and is updated for logout at IP authorization provider end. So that, the cookie on the browser will be updated and sign out will be processed smoothly.
Please find the below probable steps to update the logout URL at the Identity Provider end: -
Open the authentication provider workspace.
Find the logout URL.
Update the URL to the ‘https://RP-2/adfs/ls/?wa=wsignout1.0’ same as that configured in ADFS Server.
Save your changes.
And as for your first query why ADFS changes the chain of calls with SAML active session, it is because the cookies and cache must be removed from the system for successful logout request, thus the logout time as recorded when signing out is updated at the SaaS app end and thus, it is recommended to close the browser let it update in the system also.
Thus, recommend you open both the RP trust apps in different browser windows as both are configured for different token providers.
Please refer the below thread for more information: -
How do you handle the logout process for applications federated with ADFS?
Thanking you,
We are about to integrate our JAVA application with SSO Federation. We will get a metadata in SAML2 Assertion format and all the session tracking is taken care by SSO federation.
I am not clear how the session tracking happens with each request in our JAVA application. Our main page URL is configured in the SSO federation and after user clicks the link control comes to our application. So if I navigate to other URL apart from the one configured, how the federation track the session? Do we need to pass any metadata for each and every request?
We have been asked to share the home page URL and certificate information and SSO federation will configure those in their portal.
A Java application server normally trackes a user session using a 'JSESSIONID' cookie. Once the SAML assertion generated by an IDP(say ADFS) has been validated by the SP(the java application here) a security context /session is created which is identified by a JSESSIONID. The browser sends JSESSIONID cookie with seubsquest requests and the application verifies it and servers the requetsed resource/URL.
We have a CRM Dynamics 2016 onpremise (IFD configured), we access to the CRM from a Cordova mobile application via SOAP authentication and consume the service "Organization.svc" to get or set Data: everything works fine until now.
After adding a Web Application Proxy, the call to ADFS for the token still working, and returns a valid token. However, the second step of consuming the service "Organization.svc" is blocked : the Web Application Proxy redirects the call to the ADFS login page, which is of course not what I want.
I think the root of the problem is in the fact that the proxy cannot 'read' the SAML token I'm sending in my HTTPRequest.
Did anyone have an idea how to resolve that ?
Could you maybe inspect with Fiddler if the proxy is forwarding the required authentication cookies / headers ? I presume these are ignored by the proxy and ADFS sees the second request as not authenticated.
I have a PowerShell script that uploads a batch of files to lingq.com.
I created it the following way: I logged in to the site via browser, and made an upload manually through the web page. I grabbed the request in Fiddler, then duplicated it in PowerShell, including the authentication cookies. I'd just swap out the content of the request and send it. It wasn't pretty, but it worked and saved me an immense amount of time. The only downside was every time I had to log in to the site again, my authentication cookies got invalidated and I had to grab them again. But that I could live with.
They seem to have changed all their communication to https, because now instead of a request to
http://www.lingq.com/learn/ja/import/contents/?add
all I see in Fiddler is
"Tunnel to www.lingq.com/443"
Fiddler also gives me a warning that HTTPS decryption is disabled. When I enable it, and start capturing, Firefox gives me a certificate error when I try to access the site (or any other site that uses certificates, including Google):
www.lingq.com uses an invalid security certificate.
The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)
My script is now completely useless, every request I send returns the login page. And because of Fiddler messing up the certificates, I can't further reverse engineer the site to mimic the requests correctly.
How can I make https decryption work in Fiddler? Alternatively, is there a way my script can properly authenticate itself on the site? I have tried the steps described here:
How to make an authenticated web request in Powershell?
It didn't work at all. My guess is some sort of federated authentication is in place, but frankly I'm completely out of my depth here.
I am completely new to SiteMinder and SSO in general. I poked around on SO and CA's web site all afternoon for a basic example and can't find one. I don't care about setting up or programming SM or anything like that. All of that is already done by someone else. I just want to adapt my JS web app to use SM for authentication.
I get that SM will add a HTTP header with a key such as SM_USER that will tell me who the user is. What I don't get is -- what prevents anyone from adding this header themselves and bypassing SM entirely? What do I have to put in my server-side code to verify that the SM_USER really came from SM? I suppose secure cookies are involved...
The SM Web Agent installed on the Web Server is designed to intercept all traffic and checks to see if the resource request is...
Protected by SiteMinder
If the User has a valid SMSESSION (i.e. is Authenticated)
If 1 and 2 are true, then the WA checks the Siteminder Policy Server to see if the user is Authorized to access the requested resource.
To ensure that you don't have HTTP Header injections of user info, the SiteMinder WebAgent will rewrite all the SiteMinder specific HTTP Header information. Essentially, this means you can "trust" the SM_ info the WebAgent is presenting about the user since it is created by the Web Agent on the server and not part of the incoming request.
Because all traffic should pass through Siteminder Web Agent so even if the user sets this header it will be overwritten/removed
All Siteminder architectures do indeed make the assumption that the application just has to trust the "SM_" headers.
In practice, this may not be sufficient depending on the architecture of your application.
Basically, you have 3 cases:
The Web Agent is installed on the web server where your application runs (typical case for Apache/PHP applications): as stated above, you can trust the headers as no requests can reach your application without being filtered by the web agent.
The Web Agent is installed on a different web server than the one where your application runs, but on the same machine (typical case: SM Agent installed on an Apache front-end serving a JEE Application Server): you must ensure that no requests can directly reach your application server. Either you bind your application server to the loopback interface or you filter the ports on the server.
The Web Agent runs on a reverse proxy in front of your application. Same remark. The only solution here is to implement an IP filter on your application to only allow requests that come from your reverse proxy.
SiteMinder r12.52 contains a new functionality named Enhanced Session Assurance with DeviceDNA™. DeviceDNA can be used to ensure that the SiteMinder Session Cookie has not been tampered with. If the Session is replayed on a different machine, or from another brower instance on the same machine, DeviceDNA will catch this and block the request.
Click here to view a webcast discussing new features in CA SiteMinder r12.52
Typical enterprise architecture will be Webserver (Siteminder Agent) + AppServer (Applications)
Say IP filtering is not enabled, and webs requests are allowed directly to AppServer, bypassing webserver and the sso-agent.
If applications have to implement a solution to assert the request headers / cookies are not tampered / injected, do we have any solution simillar to the following?
Send the SM_USERID encrypted in a seperate cookie or encrypted (Sym/Asym) along with SMSESSION id
Application will use the key to decrypt the SMSESSION or SM_USERID to retrive the user id, session expiry status and any other addtional details and authorization details if applicable.
Application now trusts the user_id and do authentication