I am designing one Multi tenant based CRM system, Where tenant will be identified by sub domain. But I am a bit confuse about the authentication system, which one to use. STS using some third party tool like thinktecture Or simple membership provided by Microsoft framework.
Identity Server 3 (Thinktecture) will be your best bet.
Simple Membership is a fair bit out of date... See Brock Allen's article Think twice about using MembershipProvider (and SimpleMembership) for a good argument against Simple Membership.
Related
My enterprise application is developed in .net framework 4.5 and is using windows authentication. In which case, as we all understand, it is the underlying AD(active directory) that authenticates the user.
I have to replace windows authentication with token based authentication, keeping the .net framework 4.6 and AD(active directory). I guess oAuth is a possible solution, could you please share some thoughts on other possible solutions and as how could I get started.
HISTORY
It was common some years ago for apps to be developed for a corporate intranet, in which case Windows Authentication was a good solution. When token based authentication came along the benefits typically were:
Extend reach so that apps could be used over the internet
Support cross domain scenarios, eg APIs in a different domain
Support multiple authentication methods / policies depending on user location and device type
Write less security code and make new security features available to multiple apps
IMPLEMENTATION
An OAuth migration is a major architectural change and needs to be managed in terms of costs and benefits, though once done your apps will be quite cutting edge. Here is how Windows Authentication typically works in an OAuth 2.0 / Open Id Connect world, which requires a more complex setup:
Your UI redirects to a Cloud Authorization Server (AS), such as Azure Access Control
The AS redirects to an identity provider - such as an on premise version of ADFS (Active Directory Federation Services) - that is configured to use Windows authentication
When in the corporate intranet the user is automatically signed in and ADFS posts tokens to the AS
The AS posts different tokens to your UI
Your UI calls the API with the AS token and the API validates it
GETTING STARTED
If you decide that the effort is worthwhile then there are 2 parts to the job. Note that your application code will only ever interact with the AS and doesn't need to know or care about the authentication method:
Infrastructure migration
Updating the code in your UIs and APIs
If it helps, my blog and code samples are designed to help people deal with some of the challenges of OAuth tech. Maybe have a look at my first tutorial to get set up.
I want to develop a (REST API) web app using Spring, and for the authentication/authorization I am thinking about using OAuth 2.0, but I am not sure whether OAuth is a good option or not.
some information about my app:
1 - completely RESTful API.
2 - microservice Architecture.
3 - using the API for both web pages (maybe SPA) and mobile apps(android and ios).
4 - the API will be used only by our developers (web site developers and mobile app developers), and never by other third-party developers (as far as I know the main purpose of OAuth is for third-party applications).
based on the given information, is it a good idea using OAuth instead of a custom Spring authentication/authorization server with JWT? if yes, what are the benefits?
some disadvantages and advantages from my past experience:
Disadvantages :
OAUTH authentication payload will contain : username, password, grant_type, client_secret and client_id.
The last two ones are specific for third-party login, do they make sense for your application and clients?
Spring OAUTH is a powerful library and will do a lot behind scenes. If you will need custom behavior, it will a little bit trickier to find the right hooks.
Development time took longer (both client and server) in comparison with simple username/password login.
Advantages :
The protocol is well documented, so you will have less overhead when documenting your application.
It will be easier to integrate with third parties (if ever is required).
P.S In your initial iteration you can start with simple login and add later third party integration(both can work together)
Summary: My task is to decide how the user authentication should be implemented for the cloud-based project that should be evolved from the older WebForms application. I am at the beginning of the decision process, but I have to decide soon; so, I will appreciate your experience.
Why WebForms? The application is based on the older WebForms code, this way it should start from the WebForms code. The problem is that the application should be ready rather quickly, so the code must be reused as much as possible. Also, we do not have developers that have working knowledge with MVC. Some trade-offs are necessary. However, the log-in process will be new, and it can be implemented using the MVC approach.
What is new: The older code was built to run on the intranet web server, the users signed-in using simple login names. Security things were not that complex. The application uses the pre-ASP.NET Identity -- really old, and that part of the application should be replaced. There will be more groups of users that should work in the separate workspace (think of companies).
New acount -- authentication: The user should use valid e-mail address to ask for registration. For the new user, the e-mail should be validated as existing, and then it should be approved by the administrator dedicated for the group.
Authorization: A user will be allowed to work only with some data. Think in terms of using a single database where the user of one group should be allowed to access only the part dedicated to the group. However, there may be power users that may have more rights.
Should I focus on using ASP.NET Identity? If yes, (not being dependent on the older versions) should I start with ASP.NET Identity 3 that is currently in 3.0.0-beta7 (see https://github.com/aspnet/Identity.git), or should I stick with version 2?
ASP.NET Identity is Microsoft's main thrust for identity and membership and their newest identity library. If you are concerned about continued support then this is the library for you.
The ASP.NET Identity library supports your need for claims based authorization (in your case using roles/groups) and recording email addresses confirmation. This is available out of the box.
I would not recommend using ASP.NET Identity 3 however, as this is designed with ASP.NET vNext in mind, not something you want to do with your legacy system.
Stick with ASP.NET Identity v2.x
Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.
Say that I have two or more completely separate web applications. The might even be running on a different server and use different language & framework.
What I need to do is to share state, or at least authentication. For example if the user logs in on one of the websites and goes to another one, he will be able to authenticate using his credentials from the first website.
For example, if I have one website running e-commerce and another one is a blog, I want all the e-commerce users be able to comment on the blog with the information from their profile.
What is the best way to do this? Is it even a good idea?
The only solution that comes to my mind is abstracting away the profiles and authentication and create some kind of global profile and then use that on both of those websites. But that seems like a really complex solution considering what I need to achieve.
OpenID seems like a good way.