Can login page (where we need to enter the credentials) be tested?
And URL of that website after login page can be tested without login?
JMeter is able to simulate login event and represent authenticated user. See i.e. ASP.NET Login Testing with JMeter guide for example configuration and associated correlations.
If you need to simulate N authenticated users and X unauthenticated ones you could use Throughput Controller for scenario distribution.
Answer is Yes and To a Large extent Yes.
Yes, Because it can be done for Web Page Logins and as Dmitiri said ASP.Net logins also.
Why i am Saying "to a Large Extent" is NTLM and Kerberos Authentication for Logins can be a bit troublesome. Where you need to be sure about the Domain names, the exact details.
Now, it depends where you are being asked for the User's Credentials . Normally for a Simple Web Page login - You Would get the URL from the address bar and you need to pass that.
For NTLM and Kerberos ones, you need to do some research so as to where you are getting authenticated and grab hold of that page.
We did for NTLM one and the login and authentication pages were different.
Related
I have configured Local STS with my web application (which is hosted in IIS 7 and has the host name as www.abc.com) and it can receive the claims from the STS and it can login. Now I have added another host name (www.xyz.com) to my web application. If user a login to a page in the application using www.abc.com/page1 and it redirects to local STS and it authenticates the user and adds the security token. Now if the user visits www.xyz.com/page2 it also redirects to the STS for authentication.
If a user either logged in www.abc.com or www.xyz.com they need to access the other domain page with out login. Is it possible? How do we achieve this?
In broad strokes, if you have two different relying parties, each needs to route the user to the IDP. If the IDP is configured for single sign on, the user will only notice the routing to the IDP the first time. On the second routing, (assuming same browser session and that the routing is within the lifetime supported by the IDP) the user will be authenticated without seeing a page at the IDP and being required to present credentials.
So, part of your answer hinges around what you mean by login: if you mean "experience a challenge and enter credentials" by log in, you should be able to enable this by simply ensuring that the IDP is configured for single sign on.
On the other hand, if by login you mean the redirect to the IDP, then you need to make sure the application is able to share state across the different page names. Note that usual management of state is via cookies, and note that a cookie for abc.com will not be returned to a web page named xyz.com. There are a number of clever ways to resolve this, although i am not aware of any simple application configuration solutions. One example is to have some part of both the abc.com page and the xyz.com page accessed by the url shared.com. State cookies can then be set by the shared.com transaction when logging into abc.com and read by the shared.com transaction when subsequently accessing xyz.com.
I've never had to implement such a cross domain cookie solution and have only had off-hand conversations with colleagues about it: we've always found the silent redirect of single sign on to meet our requirements. Careful research into the privacy impact of such a solution and the likelihood that such cookies might be blocked should be considered before development.
I am implementing Spring Security login and I am trying to understand something, here is the scenario I want to implement:
For initial login show login page and let user in.
If after some inactivity session expired and user makes some action show him popup window to authenticate (js-based popup in browser). Continue with the action like there was no login form.
Implementing form is easy, but how do I make the popup work - let's say I make the request to some protected URL after session expired, how do I make sure it's not forwarded to login page, but to my login handler that shows popup window?
Another issue - I need to integrate with SiteMinder, so I would need to read the Login/Password combination and after it's read, forward to SiteMinder for authentication, after that's done I want to return without forwarding.
Answer to SiteMinder issue:
Siteminder is generally installed on a Webserver behind your servlet container.
Also, Siteminder manages the authentication and an application does not have access to a user password at all.
To integrate with Siteminder use this filter:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#d0e6295.
Answer to the login with the popup issue: since you need to integrate with Siteminder, I would not recommend to implement the login via the popup.
The sample given on the above springsource website is quite primitive and can break in several use cases. Using the SM_USER header alone has several caveats, see my answer here: How to validate SM_USER header in Spring Security preauthentication for siteminder
CA SSO aka SiteMinder, as well as other traditional html-form-request-response SSO systems, have a hard time dealing with Single Page Applications and protecting the web services that you invoke via AJAX, without breaking the flow of your application.
I've got an internal web app for my company that uses a login with google authentication system. It's working well for the most part, they can authenticate with google, give consent for my app to access basic user details, and then when they are returned to my app, I can indeed get their user details.
The issue is that I thought once they give consent they wouldn't have to do it each time. Is this an incorrect assumption? As it is now, each time they click the "login with google" they must give consent rather than being redirected back to my app.
I'm using PHP (codeigniter) and a pretty good Oauth lib found on github (fork of phil sturgeon's library). Is there some param I should be passing so the user doesn't have to give consent every time, after the first time?
Google login does not require user consent every time. If you're using OAuth2 Login procedure, you should be able to login a second time w/o re-approvals: https://developers.google.com/accounts/docs/OAuth2Login
In some contexts, however, it is possible for auto-approval to become disabled, with the subsequent requirement of user consent on every login.
The first and most common case is if your application explicitly requests Google to prompt for consent everytime. Check if your authorization request (which you may have copied from an example or sample code) includes 'prompt=consent' or the older, non-standard form 'approval_prompt=force'. Removing these parameters (if present), will likely cause auto-approval to start working.
Another situation is if your redirect URL is based on 'localhost' or some other URL that does not belong to the global DNS namespace. In this case, for security reasons, Google sets a cookie on the user's computer, in the accounts.google.com domain, to signal that the user authorized _this_device_ to login to 'foo' on localhost (or local domain); Google will only auto-approve w/o consent a 2nd request if it finds the cookie. The reason is that the meaning of 'localhost' (or local domain, or other URL not built on global DNS namespace) is device-dependent, and allowing the authorization to apply across devices could introduce security risks. So if your company has configured browsers to clear all cookies on exit, and you use a non-absolute URL, you could see your users having to consent everytime. The solution is either to host your endpoint on an Internet-valid hostname (the host doesn't need to be accessible from outside the Intranet, just the hostname needs to be globally valid), or you need to exempt accounts.google.com from the cookie clearing policy.
Updated with clarifications
Hello,
When our users go to http://mysubdomain.server.com/login they get redirected to https://secure.server.com/login?subdomain=mysubdomain. So the actual login page is located on the secure.server.com subdomain.
The problem is that if the user logs in with the credentials meant for subdomainA and tells Firefox to remember the password, the browser will autocomplete the login form even if the user visits the login page meaning to log into subdomainB.
Firefox assumes that the login form on secure.server.com/login?subdomain=subdomainA is the same with the one on secure.server.com/login?subdomain=subdomainB.
At first, I thought Firefox remembers passwords based on a combination of the URL and the name attribute of the form, but I've tried changing the name based on the subdomain (name="login-<subdomain_name>"), and it still doesn't work.
How can I make Firefox remember passwords for subdomainA and for subdomainB separately, and not together?
I couldn't quite decipher what your setup is, but you can enable login manager debugging and check what Firefox does. You can also inspect signons.sqlite in your profile to see what pieces of data are stored with the login.
I thought that for web forms it keyed off the form's submit URL, but my memory is shady on this.
[edit]
source (nsLoginManager.js) says it only uses the form's action and the page's URL, and it uses not the action/page URL itself, but (see _getPasswordOrigin) the scheme+host+port combination.
If they're actually entering data into http just to be redirected to https after login, isn't that a bad scenario? You're already sending the most sensitive piece of data unencrypted across the wire.
I believe a better solution would be to redirect them to the https site and do login there...is there something I'm missing with your setup? Do they login again on the secure site?
AFAIK domain name (complete) is the current basis for remembering login. It wasn't always so, though. I'm not sure about protocol or port number, but a.domain.com is different from b.domain.com and domain.com, but same as a.domain.com/somewhere.
I have a website that I would like to allow both Forms and Windows Auth for. My problem is that it seems that when you setup IIS to allow both anonymous (Required for forms auth) and Windows auth that the browser won't send the user's network credentials.
It just uses the anonymous login. Is there any way either in IE8 or IIS to have it try Windows Auth 1st and then fall back to Anonymous?
Thanks for any help.
You can't ask for HTTP authentication (whether that's Basic Authentication or Integrated Windows Authentication) without causing the authentication dialogue box to pop in the case where there are no credentials yet.
So in general for hybrid HTTP-auth+cookie-auth approaches you enable both anonymous and authenticated access for the bulk of the site, but allow only authenticated access to one particular script.
When the user accesses a page without either kind of auth, you spit out a page with a login form for the cookie-based auth, and also a link to the one URL that allows only authenticated access. The user can fill out the form for cookies&forms auth, or hit the link to log in with HTTP auth instead.
If the user follows that link, they will be given a 401 response and must provide HTTP authentication, either through the auth dialog, or potentially automatically using integrated Windows authentication. Once this has happened once, the browser will start submitting the same credentials to every future page, so IIS will decode the credentials to give you the expected REMOTE_USER when your main site scripts are run.
Browsers will only submit the credentials to pages in the same directory as the 401 script, or subdirectories of this. For this reason it is best to put the HTTP-auth-required script in the root, for example as /login.aspx.
However, there are a few browsers that won't automatically submit credentials for further pages, and require every HTTP request to respond 401 first, before sending the request again with credentials. This makes optional-auth and hybrid-auth schemes impossible (as well as making browsing of protected sites much slower!). The only modern browser that does this is Safari. You may not care, as Safari's support for Integrated Windows Authentication has traditionally been shaky anyway, and it can still use the forms+cookies auth type.