I already configure the logout uri in ACO and not protect it. but during I logged out. then I type some of my webapp url directly in browser, it still could access directly without a popup window which make me input the user and password.
and sometimes, first time I type and enter my url, it need user and password. then I close the popup window. and reenter the ulr, finally I can still get access without authentication and the SM_USER is still the previous user.
Do you guys meet this kind of issue?
Hi Teng Fei,
Have you configured Comprehensive Log Out and followed all the steps mentioned in below link?If not Please try it out:
I followed it. but still this problem. some page are ok, some page still no need input user and password.
Add below meta tags in logout page. And try how it works.
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
Hi BRs//Teng Fei,
When you logout from siteminder protected application, Agent will set SMSESSION=LOGGEDOFF cookie in the browser, which indicates that the user successfully logged out.
Were you able to find this cookie in the browser?
Also you mentioned, even after logout you were able to access URL directly without entering credentials. Did you check whether the logoff request went to agent or served from the browser cache ?
If it is served from Browser, We can add these settings in the logoff page.
Set up the log-out page so it cannot be cached in web browsers. This setting increases security because the page is always served from the web server, and not the cache of the browser. For example, for HTML pages, you can add the following meta tags to the page:
< META HTTP-EQUIV="Pragma" CONTENT="no-cache">< META HTTP-EQUIV="Expires" CONTENT="-1">
Yes ,I find the SMSESSION=LOGGEDOFF in mycookie. and my logout feature is based on the ****.do, it's a structs action, so I think it should go to the server side.
and I find that this issue don't exist in IE. but in chrome and firefox.
If I understand correctly, when you have logged off you try to access directly to an application URL and you are able to see the contents, but this does not happen with every page. It could be due to a cache issue if the static content is being cached:
Enables the full log-out function by specifying the URI of a custom web page. This custom web page appears to users after they are successfully logged off. Configure this page so that it cannot be stored in a browser cache. Otherwise, a browser could possibly display a log-out page from its cache without logging the user off. If this situation happens, unauthorized users could possibly have an opportunity to assume control of a session.
I hope it helps,
Actually I can see the SMSESSION is set to LOGGEDOFF in my browser.
and when I access some page, the SMSESSION comes back normal again.
I think it would required log analysis, so please raise case with CA Support, once reviewed the logs appropriate solution will be provided.
It seems that there is issue in Cache. Ensure that you have Cache is disabled for logout and login page.
As mentioned earlier, here is the code snippet for html page ( logout and login page)
Hi Teng Fei,
Also Some web browsers do not support meta tags. Use a cache-control HTTP header instead.
I now found some hint about this issue. here I use the basic auth for the policy. which means that there is a "Authorizaiton" tag record my user and password info in HTTP request header always during accessing the web app. and when I click log out. this tag is still in the browser, and still send in header each time access the web app. also, I've check the cookie in browser, seems correctly, my SMSESSION is always set to LOGOFF when I log out.
For the basic auth, is there any limitation in chrome or firefox?
Basic authentication, or “basic auth” is formally defined in the Hypertext Transfer Protocol standard, RFC 1954. When a client (your browser) connects to a web server, it sends a “WWW-Authenticate: Basic” message in the HTTP header. Shortly after that, it sends your login credentials to the server using a mild obfuscation technique called base64 encoding. When HTTPS is used, these credentials are protected, so it’s not considered insecure, which is why basic auth gained widespread use over the years. The biggest problem with basic auth has to do with the logging off the server, as most browsers tend to cache sessions and have inconsistently dealt with the need to properly close and clear connection states (or sessions) so that another (different) user couldn’t log back in by refreshing the browser.
Form-based authentication is not formalized by any RFC. In essence, it is a programmatic method of authentication that developers create to mitigate the downside of basic auth. Most implementations of form-based authentication share the following characteristics:
1) They don’t use the formal HTTP authentication techniques (basic or digest).
2) They use the standard HTML form fields to pass the username and password values to the server.
3) The server validates the credentials and then creates a “session” that is tied to a unique key that is passed between the client and server on each http put and get request.
4) When the user clicks “log off” or the server logs the user off (for example after certain idle time), the server will invalidate the session key, which makes any subsequent communication between the client and server require re-validation (resubmission of login credentials via the form) in order to establish a new session key.
As per my knowledge, logout functionality properly works with form base authentication scheme compared to basic auth.
If still persists the issue, Enable persistent session for realms and update the aco parameter MaxSessionCacheSize=0
I go back to Shankar's suggestion (which we inform customers often about and it is documented in our "Comprehensive Logout section in the product documentation):
But also note that
Important! Some web browsers do not support meta tags. Use a cache-control HTTP header instead.