I've noticed recently that some major online services (google, yahoo) are using a 2 page process to log users in. The first page asks for a user name and then once submitted a second page then requests the password.
Whats the reasoning behind doing it this way? Is it more secure?
There might be more to it than this, but:
Google for work integrates Google services with a custom domain. In such setups, it is possible that the authentication is handled by company's own LDAP (or whatever) server. In such cases, after entering the email, user is redirected to log in at their company's site rather than Google.
So, in general, it allows the actual authentication to be handled somewhere else according to the given username.
Related
I want to create a web page, that will serve to authenticate users based on credentials I give them (user1, pswd1 etc).
Only after a user authenticated, he should have access to a few other web sites,
on different folders of the web server, but which have no server side code(otherwise it would be simple.)
The user should be allowed access to the other sites, e.g. based on his IP,
for 24 hours or another period, or while he has the authentication site open on his browser.
The purpose if that the user will not have to enter credentials on each site,
and will enter his credentials only once, or once a day.
Restrictions:
I don't want to modify the target web site javascript code at all, e.g. to query a web service.
The user should be granted access using any browser,
so I assume I cannot use cookies.
If I would develop such a mechanism on Apache,I could, for example, have the authentication site PHP code add a line "Allow from ip" to the htaccess file of each target web folder, whenever a user authenticated successfully.
The issue is that I don't want to develop it as I am sure a solution already exists, and also I need a similar mechanism for both Apache and node.js (although i can live with two different solutions)
What information does the user have to identify themselves? How do you guarantee the user is who they say they are?
The whole point of authentication is to establish the user is who they say they are and that may create a session so that users need not reauthenticate.
If you want the user to authenticate in a single location and then reuse that "session" or set of credentials elsewhere, what you are looking for is single-sign-on / identity federation.
For instance, take airbnb.com. I do not need to authenticate there. All I have to do is authenticate with a third-party e.g. Google or Facebook. As a matter of fact, SO works in the same way.
One of the standards behind this technique is called Open ID Connect. Look into that. If you are willing to dish out money, you can look into commercial solutions e.g. Ping Identity. There is an open source implementation provided by Mitre / the MIT. It's available here.
In fact it occurs to me I can use simple routing.
In the top level folder have php code that does the authentication.
If the user is authenticated, route/redirect to the requested target site,
based on the requested url.
The url should be for example http://mysite/site1, where the authentication code is in the folder mysite, and site1 is not directly accessible.
Perhaps I can use something like php-express to reuse the same php code on node.js.
You all know this page.. Is there ANY way to customize this page somehow?
I thought using an iframe and custom the HTML but Google won't let
me embed their websites..
I thought using a Google Site and inserting a login gadget but there
is no login gadget.
What I want is a custom page where my clients can login to their gmail, drive....
What I want it's not impossible, this guys http://www.cloudcodes.com/custom-login-page.html offers you the possibility to custom the login page and even redirect you to another page after you've logged in.
Directly editing the native login page at accounts.google.com is not possible.
However, for Google Apps accounts, you have the option to set up the Single Sign On service, which allows you to authenticate through a third party provider (Or yourself, if you have the ability). What GControl are offering is this service, although they've labeled it misleadingly, to make you believe your actually editing the login page, rather than redirecting your users to a secure login.
They do it very well though, leveraging the Google Apps APIs to allow you to write and setup the service in their own console.
Source: I installed the service and tried their free trial, and they simply used the APIs to enable SSO on my domain.
Edit for clarity: SSO setup is not available for consumer Gmail.com accounts.
I have a main website running on AppEngine. It's on a subdomain like main.example.com. This main application is a content portal for our customers. It offers an Ajax application built on YUI. Customers can upload data to it. Users authenticate using Federated Login.
The Ajax application on it allows users to process the data previously uploaded. To do it it should use an webservice running on other subdomain like service.example.com. The webservice does not run on AppEngine but on our services - it's CPU heavy and built on other set of technologies. It would need to download the data on main application - but the downloading service - like everything on the main application - is behind the authentication wall.
I could programatically always allow the service to download wharever it wishes but I think this can turn into a major security problem.
How can I reuse the OpenID authentication "token" to allow it (the service) to appears to the main application as the authenticated user so it can download data? Or If I can do this what would be the best way to accomplish what I intend to do?
You can't really reuse the authentication token. What you should use is something akin to OAuth, though since you control both ends you can make it somewhat simpler:
Generate a shared secret, accessible by both main.example.com and service.example.com
When a user accesses service.example.com for the first time (no authentication cookie), redirect them to main.example.com/auth?continue=original_url (where original_url is the URL they attempted to access)
When you receive a request to main.example.com/auth, first log the user in the regular way (if they're not already). Then, take their user ID or other relevant credentials, and generate an HMAC from them, using the shared secret you established in step 1. Redirect the user to service.example.com/finish_auth, passing the computed HMAC, the authentication details such as user ID, and any parameters you were passed in such as the continue URL.
When you receive a request to service.example.com/finish_auth, compute the HMAC as above, and check it matches the passed in one. If it does, you know the request is a legitimate one. Set an authentication cookie on service.example.com containing any relevant details, and redirect the user back to their original URL.
This sounds complicated, but it's fairly straightforward in implementation. This is a standard way to 'pass' credentials between mutually trusting systems, and it's not unlike what a lot of SSO systems use.
I need to work out a way to setup the validation of the users of a web application before they've actually arrived at the site. That is, someone browses to a url, enters a username and password which is then validated against a db or whatever. They are then automatically redirected to the real web application, on a different domain out across the internet, which is passed the details of the user and which then lets them through to the site without asking for the credentials again. And this must be done as securely as possible.
What are the options available for this sort of problem?
Thanks,
What you are describing is a typical use case of intern-domain web authentication. There are multiple ways to do it,
If both domains belong to the same application/company, you can just do your authentication and then pass some token/secret to the other domain in your redirect. The other domain can drop another cookie to maintain the session. This is practically how it's done between different domains all popular websites. For example, flickr.com uses yahoo.com to login.
You can use Identity Federation if the domains are closely related (partners). Most popular mechanism to achieve this is through SAML.
OpenID can also be used (That's how you arrived at this site) if the sites are loosely connected. OpenID uses arcane login URL so it only makes sense for tech-savvy users. The regular user may easily get confused by its complicated login process and consent page.
OAuth is an authorization scheme. It's not designed for federated login but you might be able to use it.
Look up OAuth or OpenID.
We are developing a Intranet portal that uses integrated authentication, but a few sections of the site will be exposed to users who are not in the domain. For those users we plan to use anonymous access. However, our display logic for the entire application is based on the user logged into the portal, so we are not fully comfortable with this approach. The URL has to be same for both types of users and transitioning between both the environments has to be seamless.
We tried using user controls in pages to authenticate but things didnt pan out. When the page is reached the standard windows authentication grey box pops up.
Is there any way to intercept the request at the IIS level like an HTTP application?
If applicable we would disable anonymous access and for unauthenticated users we will impersonate with a least privileged domain account and redirect to the home page.
SharePoint isn't really designed for the scenario you describe of mixing types of authentication. It dedicates a web application to one type of authentication. You can then 'extend' that web application to use another type of authentication on another address. For example, your intranet portal would use Windows authentication. It could then be extended to use anonymous authentication on another port or domain name.
One option for what you describe is to configure two separate web applications. One is for users that need to authenticate. The other is for anonymous access. Configure the content in the appropriate locations and link between the two as necessary. Users within your domain should not receive a login prompt when connecting to the authenticated site if you use this approach. Users outside your domain will receive a login box and won't be able to access.
Consider using forms authentication for users outside your domain if they need to access your intranet. (Once again the 'forms authenticated' part of your site would be extended to a unique domain name or port.) This would mean they will be prompted to enter their credentials in a form on the page when first connecting.
Read more about authentication on the Authentication Resource Center.
A couple of final points... If you can use SharePoint's default authentication mechanisms rather than writing your own controls, use them as they are well tested and secure. Also, don't be tempted to change SharePoint's IIS settings unless you are certain there is no other way to do what you need. SharePoint regularly updates these itself and may overwrite your changes (or give you grief in other ways).