We need a new authentication server for our large business system (ERP). The previous authentication server was internally developed. Now that we need a new one we will first try to find an already existing authentication server that we can use. Can anyone recommend an authentication server? Remember that this is a business system, so things like Facebook login is not an option. Do microsoft / google or others have any authentication servers that can be installed and run locally?
Seems like you need to store the usernames in your DB, because you do not want to be dependent on 3rd party to store them for you. Furthermore, you do not want to force your users to have accounts in the 3rd party (e.g. Facebook, Google).
So AFAIK, the only option for you is to maintain your own authentication-server...
The good news: you have oauth-2 packages that you can use, and I've written a project that implements all authentication-server flows, such as registration, forgot password, etc.
You can see a demo here.
HTH.
Related
I need to store password that our users use to connect to third party services (primarily their database). To add complexity to this, the user might be able to add more users later (of course with the same permission levels) so they would be able to connect to those services as well. What would be the best (secure) way to do it?
Storing the hash (and salt) won't be an option since we need to use the password to access to their third party services.
I know there is oAuth option, but their third party service might not have oauth in place. Also not sure if configuring oauth on their database would be that simple.
Another option is to have another system for storing the password (eg. KMS). Encrypt the service's password with the user's own password (master password) so the system can decrypt it later (but not without user's own password).
Something like these:
How do I securely store passwords to a 3rd party webservice in my database?
Security model: log in to third-party site with user's credentials
Is there a better way to do this kind of thing? What would be the security model look like and the checklist to securing it? Or even should I refrain from developing this system at all? Any insight would really be appreciated.
** EDIT **
As some comments suggested, I might be not clear enough on the situation and goals here. So to clarify:
We are trying to build a No-Code feature in which user might be able to connect to third party services holding their data or their own database. Something like Bubble
As for the goals (and threats), we are trying to make the key (password) relatively un-readable (and un-usable) by external threat or even our own developer but our system (with authorisation from the owner) can still use it
Not sure if this is ok to ask here (otherwise just ignore it), but I wonder what kind of method system like Bubble (their database connector plugin) use
The links I showed (and given by gusto2) above recommend the use of HSM, which is costly (even for the cloud solution). Is there a lower cost alternative method?
I have in the past done a hand rolled app that stores a user token on client side $window.sessionStorage.
I have since then realized this is not safe. I am now looking for the most safe, standard way to secure an app that uses a node/express backend api that I will make, and also uses a front end that makes requests to this api such as angular for web or a native mobile app. Plus, whenever I would close the browser, I would have to re-log in because the $window's session storage was wiped out.
From what I've researched thus far, one of the safest ways to date if you're going to handroll it is to store a jwt in an http only secure cookie.
However, I'd kind of like to use a service that already exists, such as oAuth. Couple questions:
1) How safe is oAuth in terms of keeping ownershp of your userbase? What if 3 years from now oAuth just suddenly or slowly dies out? Aren't all my users technically stored on their server? How would I keep my users native to my app?
2) If I'm going to be creating a startup app in the same realm as snapchat, twitter, tumblr, etc... would it be generally recommended to use a service like oAuth to handle my authentication? Of course the future is unknown, but assuming the best, that my app would reach millions of users, would using a service like oAuth still be a smart choice? It seems like once you start using oAuth, there's never any going back to storing your users in your own database a year or two down the road.
Thanks
OAuth is an open standard for authorization.
Maybe you're thinking about Auth0. There are a lot of services that can handle user authorization for you, including Auth0, Stormpath, Apigee, UserApp, AuthRocket or Amazon Cognito. Whichever you choose, make sure that you can get the database from them in case you want to stop using their service. Not everyone explicitly offers an easy way to leave them but if that's important for you then make sure who suits your needs and who doesn't, and base your decision on that.
As for OAuth, see the https://en.wikipedia.org/wiki/OAuth article.
There's a huge list of OAuth providers on Wikipedia but those are services like Twitter, Google or Facebook. In a way you can use one of those services to manage all your logins but as soon as they see you as their competition, you're in trouble. I've heard stories like that.
Some interesting read on the subject:
The dangers of OAuth/Social Login
Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services
OpenID Vulnerability report: Data confusion
Social Login Setups – The Good, the Bad and the Ugly
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).
So I've read numerous articles on a password system for a web app, and they all seem very confusing. Some say you need to hash your PW's AND establish an https secure connection, others say you just need to hash AND salt your PW's.
I just know, after this has been done millions of times, there's PROBABLY some sort of library out there that can do a bunch of things for me for a password inputted on a client side, and give me something to save securely in my SQL Server 2008 database.
Do I need to worry about all the https secure connection stuff? Can I just make sure I hash the PW correctly? To hash it, do I need any external libraries or can I create a secure user/pw system entirely in .NET?
I've never done this before so any articles, tips, links would be very helpful. Thanks.
If you don't want to roll your own you can always use ASP.Net Membership
ASP.NET membership gives you a built-in way to validate and store user credentials. ASP.NET membership therefore helps you manage user authentication in your Web sites. You can use ASP.NET membership with ASP.NET forms authentication by using with the ASP.NET login controls to create a complete system for authenticating users.
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and supporting data) in Microsoft SQL Server, Active Directory, or an alternative data store.
Authenticating users who visit your site. You can authenticate users programmatically, or you can use the ASP.NET login controls to create a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting them . Depending on membership options you choose, the membership system can also provide an automated password-reset system that takes a user-supplied question and response.
Exposing a unique identification for authenticated users that you can use in your own applications and that also integrates with the ASP.NET personalization and role-management (authorization) systems.
Specifying a custom membership provider, which allows you to substitute your own code to manage membership and maintain membership data in a custom data store
Configuring an ASP.NET Application to Use Membership
There's also a project on github called Membership Starter Kit for MVC
The default MVC3 Internet Application template (file-new project) has this setup for you already, simply add [Authorize()] to the controllers/methods you want to protect. Don't roll something new, use what's there for you. In addition, please use SSL as someone can easily steal a session by sniffing traffic and simply using your cookie. It's that easy.
Looking for a pointer in the right direction ...
Is there a mechanism which allows you to configure SharePoint in such a way that:
if a user has been successfully authenticated within a SharePoint site that there is some kind of "authentication token" what can be passed or is available to 3rd party sites
or a way for 3rd party sites to "recognize" that the user is currently authenticated within a sharepoint environment
all 3rd party apps can be modified to accommodate whatever needs to be done
but the constraint is: SharePoint may or may not be a hosted (by a separate service provider) and how the original authentication took place is irrelevant i.e. just need to know they authenticated ok, not how
EDIT
scenario to help clarify:
authenticated SP users require access to a 3rd party service provider for additional content. a "link" on their SP site redirects through to the 3rd party. the 3rd party needs to recognize the referrer (based on a collection of evidence supplied by the request) so that it need not challenge for a secondary authentication process.
one of the 3rd parties is me. the SP instances are many and varied and would be any one of my clients (which i don't offer support to, just provide a content service to).
so the attempt is to solve more of a general "community/ecosystem" problem.
Going on the small amount of information available here.... You are probably going to use Windows Authentication (via Active Directory) or Forms based authentication.
If you are using AD within your organization and the other server you are authenticating to is using the same AD, it's a no brainer. If it's AD based but both servers are using different domains, it's much more complex. One option would be to setup a trusted share between the ADs.
If you are using Forms Based authentication it becomes a bit more of an issue. If both servers are using the same FBA, you could create the authentication cookie in SharePoint and then add the cookie as a header to a Request object and then redirect to the server.
If they are different authentication methods totally, you need to determine if your security requirements will allow users to authenticate via some URL based mechanism (like querystrings) and then develop the logic on your SP box to create the URL to authentication.
Your requirements are a little vuage but this should point you in the right direction.
Plan authentication methods (SharePoint Server 2010)
Specifically Claims based authentication.
I'm guessing that by "3rd party sites" you mean sites that aren't hosted in your domain. If that's the case, then the servers won't be able to use your AD authentication (unless you share them, which probably isn't worth it).
I would suggest modifying the way users are authenticated on the 3rd party servers, as you have control over how you send your users over there. You could easily encrypt their usernames/emails/unique IDs and a timestamp (to make sure they can't bookmark that link) in a query string.
The information is then decrypted on the 3rd party server. Invalid information and they are redirected to your login page. Valid information and the 3rd knows that they were authenticated in your sharepoint app.
Your question is very confusing.
SharePoint may or may not be a hosted
What do you mean by that?
Are you invoking a 3rd party web app from a SharePoint page? You can get the current user using SPWeb.CurrentUser property and make use of it.