Good afternoon everyone.
In the team we plan to make n applications that are very different from the others but we need that with a single time that the user authenticates he has access to all of them.
The applications will be under a single domain.
domain.com
app1.domain.com
app2.domain.com
app3.domain.com
So we want to implement an authentication scheme very similar to google's, where 2 additional subdomains are managed:
accounts.domain.com: to handle all authentication rules (eg login, signup, forgot password, etc.)
myaccount.domain.com: to manage all the user's personal information, subscriptions, security settings, etc.
The questions are as follows:
What is the safest and best way to do this?
What database-level considerations should we take into account?
What general considerations should we take into account to avoid
future problems?
For what it's worth, the stack we are going to use is nestjs + mongodb + graphql
Thank you very much.
The easiest and safest way to manage this is to use a proxy that accesses the services instead of the user directly communicating with them. Then they only have to authenticate against the proxy.
Your other options require some sort of central authentication provider. This could be done a number of ways (assuming you control all the involved services). You could use a shared cross domain cookie or use some sort of oauth flow depending on your requirements.
Related
As with many applications, my service's authentication logic lives in the application code. Now however, I need to expand my authentication to incorporate 3rd party identity providers for single sign on.
I want to retain the old authentication behavior (database lookup) but also want to add support for 3rd party identity providers.
With this increase in complexity, does it make sense to separate the authentication logic to its own service? In this model the application server will redirect unauthenticated users to the authentication server. After authentication is successful, the authentication server will redirect back to the application server.
Is this approach sound?
If you have available servers and infrastructure budget, let your web application perform the authentication, using a community maintained library.
Generally its no recommended to build one by yourself.
Store your users in a database table.
Authentication using other sites problems:
Your visitor may not want to have an account with 3rd party site.
It results in giving too much information to the 3rd party site (who share much of it with other sites which use their authentication mechanism).
It is generally a good idea to separate your authentication logic and have a different service perform that task. This is also true for other 'cross cutting' concerns such as authorization and SSL offloading. It gives you a simpler development environment and in general an app that is easier to reason about (for example, you don't have to worry about authentication while in development mode and you can develop the services independently which goes a long way in terms of productivity and velocity).
In order to compose the authentication service with your application, it is better to have a third component that orchestrates and routes the calls accordingly (as opposed to having autentication related code in your application).
I have external customers with their own intranet sites that have links to our web application. Once their employees have logged into their intranet they don't want them to have to enter separate credentials when they follow the links to us.
What are some options for offering a single sign on for them such that we bear the majority of the technical cost for setup and that we can use with as many customers as we want. Seems like it should be a solved problem but I have not been able to find an appropriate solution (other than coming up with something completely custom).
To be clear, employees already have accounts on our application.
You don't specify which platform you are on, but you should look into authentication federation. The idea is that their intranet site produces a security token that you trust to authenticate their users on your site.
On the Windows platform, WS-Federation is typically used. On non-Windows platforms, the SAML protocol is more popular. Security protocol can use different token formats like SAML or JWT.
After further investigation, I finally found some standard protocols for doing this:
JWT - http://www.intridea.com/blog/2013/11/7/json-web-token-the-useful-little-standard-you-haven-t-heard-about
SAML - http://wso2.com/library/articles/2014/02/introduction-to-security-assertion-markup-language-2.0/
For my purposes, I think JWT is best because it requires the least amount of effort to integrate.
Kerberos, NTLM, forms, claims based, use of active directory?
Going through the difficult process of analyzing which authentication method to use for a Sharepoint build-out, and I must be honest in saying that I'm confused as to which the best use-case would be. It's going to be used as an intranet and extranet, and am wondering what authentication methods other people are using and why they chose the authentication method they did.
Many thanks!
We use claims based kerberos.
Claims based because we started with Windows authentication, but want to leave the option for enabling forms based authentication open. (Forms based authentication is not available in classic mode)
Kerberos because it allows us to overcome the double-hop problem.
Setting up Kerberos brings some additional configuration requirements. Although it may seem intimidating at first, it is well documented: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1a794fb5-77d0-475c-8738-ea04d3de1147&displaylang=en
Also claims based authentication has it's problems/limitations, but until now I didn't encounter something that made me change my mind about it.
In your case, if you want to make your SharePoint available as an extranet environment, you may want to go for claims based authentication. That way you can use Windows authentication for internal people and forms authentication for external people (customers/suppliers/...).
When making integrations NTLM is the preferred one, Kerberos is nice (and safer) but if the AD goes down your intranets and extranets wont be accessible.
So, Kerberos if you are paranoid, NTLM if you want high availability and good enough security.
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.
So I like the OpenID idea. I support it on my site, and use it wherever it's possible (like here!). But I am not clear about one thing.
A site that supports OpenID basically accepts any OpenID provider out there, right? How does that work with sites that want to reduce bot-signups? What's to stop a malicious OpenID provider from setting up unlimited bot IDs automatically?
I have some ideas, and will post them as a possible answer, but I was wondering if anyone can see something obvious that I've missed?
You have confused two different things - identification and authorization. Just because you know who somebody is, it doesn't mean you have to automatically give them permission to do anything. Simon Willison covers this nicely in An OpenID is not an account! More discussion on whitelisting is available in Social whitelisting with OpenID.
The short answer to your question is, "It doesn't." OpenID deliberately provides only a mechanism for having a centralized authentication site; it's up to you to decide which OpenID providers you personally consider acceptable. For example, Microsoft recently decided to allow OpenID on its Healthvault site only from a select few providers. A company may decide only to allow OpenID logins from its LDAP-backed access point, a government agency may only accept OpenIDs from biometrics-backed sites, and a blog might only accept TypePad due to their intense spam vetting.
There seems to be a lot of confusion over OpenID. Its original goal was simply to provide a standard login mechanism so that, when I need a secure login mechanism, I can select from any or all OpenID providers to handle that for me. Allowing anyone anywhere to set up their own trusted OpenID provider was never the goal. Doing the second effectively is impossible—after all, even with encryption, there's no reason you can't set up your own provider to securely lie and say it's authenticating whomever you want. Having a single, standardized login mechanism is itself already a great step forward.
OpenId isn't much more than the username and password a user selects when registering for your site. You don't rely on the OpenId framework to weed out bots; your registration system should still be doing that.
Possible solution - you can still ask new IDs to pass a CAPTCHA test. Just like bots can sign up with fake/multiple email addresses to any site, but fail the "verification" step there as well.
Or are we going to have to start maintaining provider blacklists? Those won't really work very well, given how trivially easy it is to set up a new provider.
As far as I can tell, OpenID addresses only identification, not authorization. Stopping bots is a matter of authorization.
Notice that unlike conventional "per site" logins, OpenID gives you an identity that potentially transcends individual sites. Better yet, this identity is even a URI so its perfect for using with RDF to exchange or query arbitrary metadata about the identity.
You can do a few things with an OpenID that you can't do with a conventional username from a new user.
Firstly you can do some simple whitelist operations. If *.bigcorp.example are OpenIDs from Big Corp employees and you know Big Corp aren't spammers, then you can whitelist those OpenIDs. This ought to work well for sites that are semi-closed, maybe it's a social site for current and past employees.
Better though, you can make inferences from the other places that specific OpenID has been used. Suppose you have a map of OpenIDs to reputation values from Stackoverflow.com. When someone shows up at your web forum with an OpenID, you can see if they have decent reputation at Stackoverflow and skip the CAPTCHA or probationary period for those users.