I know how to implement a spring security login form the "classical" way, but I'm having a hard time figuring out how to implement a login form that opens in a modal and always behaves "properly".
It is not as trivial as it sounds.
Here are my specifications:
when an unauthenticated user requests a protected page, a modal login form should appear; when the login is successful, the requested page should appear and the address bar should display the requested url as in a non-modal approach
when this is triggered from outside the site, the modal should open on the site home page
when this is triggered from inside the site, the modal should open on the current page
when a user clicks on a "login" button on the site header (from any unprotected page) a modal login form should appear without changing page; when the login is successful, the location should not change but the page should be reloaded in order to be updated (e.g. showing the user name in the header)
if the modal is closed before submission, the original page should not have changed
if there are login errors, they should appear in the modal without redrawing the whole page
if the login form is submitted after session expiration, the login process should handle expired CSRF tokens gracefully (but I might consider removing them altogether for the login form, where I don't think are needed anyway)
every ajax request on the site (that originates from a protected page), should handle login requests gracefully
brute-force attacks should be hampered by temporarily suspending a username after some failed attempts
Java-only Spring configuration (no XML) and JQuery
the logout link should not trigger an authorization error when the session is expired
Related
Scenario:
I have two application to which login is done using pingfederate single sign service.
1.User try to login into first application but as user is unauthenticated user is redirected to login page of pingfederate (universal sign in page). User logs into the first application.
2.User try to login into second application as user was already authenticated by single sign service pingfederate provide application with necessary information(information required to set session) and user is redirected to second application.
Problem:
When User logout from first application then user gets logout successfully. At this point pingfederate knows about all open application and send then logout callback. So it sends logout request to second application. Second application handles the logout request and clears the session. But user stays on the same page. user is not redirected to the login page
Question:
How can be this be implemented that when we receive logout request redirect user to login page?
The way SLO is supposed to work for SP-Init SLO is:
You click logout at the FIRST SP application.
You are redirected to the IdP with a LogoutRequest.
The IdP then sends you, serially, to all the other SPs with
LogoutRequests. Every one of those must provide a SAMLResponse back
to the IdP with a status.
The IdP, after receiving the final status, must send the
user/browser back to the originating SP with a SAMLResponse with the
final status, which the SP acts upon.
In IdP-Init SLO, it's basically only step 3.
Here's the kicker, though, and I think gets to the heart of your question. If a single one of those SP's "misbehaves", i.e., does not respond to, or support, SLO (there is no requirement for them to support SLO), then it will break the "chain" of logouts, if you redirect to it! The IdP will redirect off to the SP, and the there the browser will stay. Once the chain has been broken, there is no way to get it started again.
I discussed this problem in my blog post "SLO - Proceed With Caution", a bit more than a year ago. Ultimately, with many of the big-name SP's out there not supporting SLO, there's not much of a reason to do it - it's just going to give you, as an SAML administrator, a black eye. Or heartburn. Or both.
I am using WSFederationAuthenticationModule for authentication. When the user is not authenticated it redirects them to ADFS web agent accordingly. The ADFS cookie lasts longer than the app session, so sometimes they will just be looped right back into the application.
Pretty much every time this is what I want, the user tries to do something, it redirects them if the session is expired and they come back around (either after logging in again or after it finds the cookie to still be good) and then they can do what they want. However, if they are clicking 'logout' I want them to be logged out. But the Module is intercepting and sending them back around and then they have to click 'logout' again once the session is restored.
Logout is an MVC api controller action. I am not sure if I want to take it out from behind the security because it also triggers some clean-up things for the app (I realize this is also a problem because potentially if they never click logout those things won't happen but that is a different issue).
I feel like I must be missing something with WSFederationAuthenticationModule and ADFS... something just doesn't feel right about making the logout action an anonymous/public action. There must be some consideration for this in the intentions of WSFederationAuthenticationModule but I can't seem to pin it down.
As far as I understand Your authentication is kept via an Auth cookie. You should try adding the following in your app controller under your logout action:
FederatedAuthentication.SessionAuthenticationModule.SignOut();
return View("LogOut");
This will log them out. Now if the "LogOut" view cannot be accessed by an unauthenticated person it will redirect back to your login page for login.
One more thing, if what you mean above is that after the session expiration when someone tries to access the logout page (although their session is anyhow expired already) they are first redirected to the login module to authenticate (since they need to be authenticated for access to the logout page), huh you could do something like this:
if (User.Identity.IsAuthenticated)
...u'r logout logic goes here together with other clean-up...
else
...u could choose to return a view which says he is already logged out
or on the login service side (if you control it) check where is the request coming from and take action accordingly.
I'm developing a mobile application using MVC 4. And I'm securing it. The application has 2 pages ("home" and "Clientes")
When the application starts it asks me for a username and password, with this being its URL http://localhost:59170/Account/Login?ReturnUrl=%2f.
I login and go to the home page. This is the url I can see on IE http://localhost:59170/Account/Login?ReturnUrl=%2f.
From this page I go to the Clientes page. This is the url that I can see on IE http://localhost:59170/Account/Login?ReturnUrl=%2f#/Clientes. At the moment all works ok (Though url like something stranger).
The problem occurs when I press the back button on IE. It must go to the home page but I go to http://localhost:59170/Account/Login?ReturnUrl=%2f#/Account/Login?ReturnUrl=%2f where it asks me to login.
What might cause this behaviour and how do I solve it?
Each time you request a page that requires authentication, .NET will redirect you to your designated login page and append the requested URL to the URL. That way, once the user has logged in successfully it will redirect them to the page they requested automatically. In your first URL for example the return URL encoded representation of / i.e. the root/ homepage of your site
It will keep redirecting you until you have authenticated. If you don't want to have authentication on your homepage then just annotate your account controller with [Authorize] and not your home controller
When running a mobile site in iOS full screen mode, using the "apple-mobile-web-app-capable" meta tag, I am using a combination of AJAX and synchronous page requests, including redirects, with success while the user is logged in.
However, when the user logs out and the session is destroyed, the iOS device leaves full screen mode and opens the login page in a Mobile Safari window.
Here is a common sequence of events:
User clicks button on Home Screen to launch mobile site in iOS full
screen mode
Server redirects user to login page for authentication (still in full screen)
User logs in, and is redirected back to mobile home (still in full screen)
User performs various actions, via GET and POST, some using AJAX and some not (still in full screen)
User hits logout button, which destroys session and redirects back to login page
Mobile Safari window opens to render login page this second time
I have tried 301, 302 and 303 redirects on logout success and nothing seems to change this behavior. It seems related to the user's session ending when running in full screen mode. I don't think this matters, but the security mechanism is implemented via Spring Security running on Tomcat.
Is there any way to prevent this behavior? I would prefer not to use a location.href client side redirect on logout.
You can cancel a links default behaviour by using jQuery's event delegation to assign a single, top-level event handler to all links on the page. When a click event is detected, we cancel the default behavior (which is to open in mobile Safari) and then manually change the window's location. This approach allows the page to be changed without breaking the iPhone standalone application experience.
http://www.bennadel.com/blog/2302-Preventing-Links-In-Standalone-iPhone-Applications-From-Opening-In-Mobile-Safari.htm
I was under the impression from running into this previously that any non-ajax/ javascript navigation would cause the app to jump into safari to serve the page
I'm using the Oauth redirect authorization method to provide authorization for a page tab iframe application.
The flow works like this:
User loads page tab (unauthorized)
User clicks authorize link
Authorization dialog takes over parent window
Accepted authorization redirects to my application to register user account using authorized email.
My application redirects back to the page tab
Loading the page tab causes authorization to be lost, and the user sees the authorize link again. Rinse, repeat, no success.
Confusingly, the application works completely if instead of redirecting to the Facebook Page Tab, I redirect to any path in my application (ie. the root, the user's page, etc.). Only by setting the redirect to the Facebook Page Tab URL does the user get "booted".
Even stranger, if I keep redirection limited to my application, but simply load the Facebook Page Tab, the authorization is killed everywhere. Meaning, post-facebook-page-load, refreshing the application off-Facebook will prompt the user to authorize again, and they are effectively "logged out" of my system.
I am using Rails 3.0.1 with Devise 1.4.2 for user accounts. The user authorization is passed to a Devise registration (I need to keep track of users in my app - a voting-based "contest" application). Devise uses the "Server side Flow" detailed here: http://developers.facebook.com/docs/authentication/
I'm lost as to what would be causing this. Facebook killing the auth cookie? Does this happen?
When you access the facebook tab page first time,signed_request is necessary:
#signed_request = oauth.parse_signed_request(params[:signed_request])
So you can send a parameter when redirect to it from other pages to check if it's the first time.