I'm working on building a series of micro-services using Aspnet Core. A mobile application, desktop application and web-application will consume the services over Http REST APIs.
For user auth, I'm utilizing the Aspnet Core Identity platform, but I'm exposing the creation of user accounts via a REST API. The clients make a REST call with the credential information and my API uses the Microsoft Identity APIs to provision the user. The user would be authorized to hit the individual resource servers with an auth server using IdentityServer4.
I have two questions that I've not been able to find clear guidance on from a security stand-point. Should the Aspnet Core project that utilizes Microsoft Identity for user creation be in an independent Aspnet Core project from the project that handles auth via IdentityServer4? Are there downsides do separating the two out that I need to consider?
The Microsoft Identity API has template and Razor Views that can be used to handle the auth from a server-side perspective, including redirects on account creation or sign-in etc. If I'm doing everything via SPA or Client-side native apps, is there anything wrong with just providing a POST API that accepts the user information, creates the account via UserManager<T> and returns the UserId?
I want to provide a dedicated sign-in page, similar to FB/Google/Twitter etc for Auth to happen across any app that wants to authorize a user for my services. I don't typically see account creation as part of the OAuth process though. Is it typical that you would allow for redirects to an account creation page, that redirects back to a client upon successful account creation or is that process typically just used for Auth via OAuth flows?
I would suggest to consider using one service for IDS4 and ASP.NET Identity since they can be integrated and give you the full functionality you're looking for(auth, and users management).
IDS4 has examples and good documentations regarding that.
To me, I think separating them would be an over engineering.
one example: when IDS4 generate access token for a user, you should get claims, roles and validate username and password, all of that are stored in ASP.NET Identity.
So for more details you can check the docs of Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html
or it's my pleasure to check my little blog post that I tried to give some more detailed and step by step.
https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/
Start with IDS4 link because it might be enough :)
The main point when thinking about security management UI is how to secure that UI. And the most safe approach for today is cookie-based auth with same-site cookie (the way, MVC uses by default). Consider that when and if selecting serverless SPA pattern. For management purposes-app having strict backend is much more secure than token-based access to distributed api-s.
Regarding the application hosting, #VidmantasBlazevicius is absolutely right, there is no the only strategy: hosting all the services in one app is simpler, so it better fit lo to middle loaded systems. But with raise of the number of users and authentication requests, you might want to scale, and separating management UI from authentication is one of the ways to handle that.
Related
I have a very basic question as I was watching few tutorials related to Microservices. If I am creating multiple microservices for 1 application, should I need to implement Authentication and Authorization for all microservices? For example If I have an e-commerce website and I have multiple microservices with certain endpoints for the purchase model.
As a user when I login to the UI, initially calling in AccountManagement microservice ( which has few functionality such Register/Login/Reset/Revoke) and then move from one feature to another which interim calls another microservice (should the next microservice read the cookie information and authenticate automatically ? Is that how it works?
Will my other microservices also have all features of the Account management microservice or only authenticating through Refresh token?
I am fairly new to this concept in microservices and trying to grasp as much as I can through tutorials but these questions are something I still struggle to understand properly.
Answer 1.
Token Based Authentication
It is always ok for you to build stateful application for monolith but not for stateless microservices. Session-based authentication works well for Monolith. However, for microservices since you need to route requests to multiple independent services. To maintain statelessness in our system, we opted to use token authentication. We packaged user claims in the jwt. Hence, we need Authentication for Microservice.
You can apply SSO based approach.
When a user logs in for the first time from any frontend app, a cookie called jwt-token gets created on the api-gateway. The cookie’s domain is .myorg.com and hence accessible to all myorg.com subdomain. When a request is made from any of the frontend apps to the api gateway, we extract the cookie named jwt-token if set. If not set, we assume the user is not logged in and return a 401-status code from the api-gateway.
If your microservices are not exposed to internet, you can also introduce basic authentication. This will also make sure reducing any security risks internal to your company.
Answer 2.
Microservice follow DDD (Domain Drive Design) Principle which makes them independent small application. You should not add any functionality of Account management (it is an independent Service). Other Service should have their authentication along with their domain which can be like Customer, Payment, Audit etc.
Refer These articles :
https://medium.com/technology-learning/how-we-solved-authentication-and-authorization-in-our-microservice-architecture-994539d1b6e6
https://medium.com/walmartglobaltech/building-domain-driven-microservices-af688aa1b1b8
I'm creating a centralized authentication system for multiple mobile applications. Its architecture is based on the OpenID Connect flow through the use of OAuth2.0 with IdentityServer4 on ASP.NET Core Identity.
I have researched a lot and in the main implementations with the Authorization Code Flow observed there is always the redirection of the user from the mobile app UI to the server web views, to allow the management of its profile.
This is very uncomfortable, because it significantly compromises the UX. I would like the user to be able to register and authenticate himself directly from the app interface without any redirection that involves opening a browser. Is there a way to do this with only API calls, from the client backend to the centralized authorization server?
You can use the Resource Owner Password Credentials grant type where you can pass the user credentials to the token endpoint and receive an access token. But usage of the ROPC grant type is highly discouraged as you can read in this blog post from Scott Brady, one of the creators of Identity Server.
What I can propose to you is to use Authorization Code flow to login the user and get access token for them, and then creating your custom API endpoints on identity server for user management. More on custom api endpoints here
I've been tasked with enabling authentication and authorization for our project's api. The main goal is to protect the methods from misuse, however we also need to enable a developer from another company to call the methods in their code.
Being new to authentication and authorization I'm overwhelmed with the many different options available for .NET etc. Some techniques look promising until you read that they pass credentials in plain text (basic auth?) or have other issues etc... I'm just looking for a reliable and safe approach.
I'm using IIS to host the web api, and I have seen that one such option is to authenticate at the 'host level'. My supervisor has mentioned this is the preferred approach.
I have looked at many threads and videos regarding authenticating in IIS. From what I can work out, such a solution alerts the user that a certain action requires authentication and to enter their credentials.
My issues are as follows:
Given the other developer is not a member of our domain, how can they authenticate using their (windows?) credentials. Is there an alternative to windows authentication?
How will requiring authorization on certain api actions impact the function of the site normally? I.e. will I have to pass valid credentials to the api in my code, for each request?
Overall I'm just a bit uncertain on how this all works and I appreciate any advice given.
I am learning to develop asp.net Web API with AngularJS frontend framework. I have been doing a lot of research on this for about a week now.I have read about oauth 2, owin and other. But now confused which is better.
I have a couple of Question and hope you guys can help me with it.
1) In my application - Only Registered User will be able to have access in to application through log-in with email and password. Can someone please point me to a good resource or article on how to create a good registration and log-in authentication with API.Which is secure enough as i will be gathering user data and storing them.
2) What type of security i need to protect my API, at first the API would be behind the firewall and then ones project is finished it will be open to the world? and also please point me to right direction if possible.
Please note this is not a duplicate question i have been through most of the post on stackoverflow and asking this after i could not find answer.
Any suggestion or help on this is appreciated.
Thanks for all your effort on this topic
You can use token based authentication using Asp.Net Web API 2, OWIN, Asp.Net Identity and AngularJS.
Asp.Net Web API now fully supports OWIN. Katana is microsofts OWIN implementation.
Asp.Net Web API now supports authorization using OAuth 2.0. OAuth is made possible with Microsoft OWIN components.
Are yo confused with the terms Identity,OWIN,OAuth ... here is brief overview of them.
Asp.Net Identity is developed to overcome problems by asp.net membership system. Asp.Net Identity allows us to use different storages(Table storage,No SQL) and allows us to use external identity providers as it uses OWIN.
OWIN is to break tight coupling b/w Asp.Net and IIS. OWIN is just a specification. Katana is Microsoft's OWIN implementation. OWIN sits in http request pipeline. OWIN pipeline has middleware components, where we can mention external login mechanisms.
OAuth was created to remove the need for users to share their passwords with third-party applications.
Note:
Here Asp.Net Identity has nothing to do with OWIN, OAuth and vice versa. They are three separate concepts. Asp.Net Identity is Microsoft's implementation. OWIN, OAuth are open
standard concepts. Because Microsoft has implemented OWIN, OAuth is made possible.
So, Web API 2 uses OAuth bearer token instead of forms authentication cookie, which is more correct in Web API world. Because it allows to use variety of end user devices like mobile devices.
In your case, you can use the default templates provided in visual studio 2013.
1. Create New Project and select Asp.Net web application.
2. Select Web API or SPA template.
3. Change authentication and Select individual user accounts.
4. Click Ok.
Now, everything is configured by default in order to use OWIN, Asp.Net Identity, OAuth. Be cause we use token based authentication, you can find there is no login method available in Account Controller.
To register users, use Register method available in AccountController
To login, you need to post data in following format to
http://example.com/token (Which can be configured in StartUp.Auth.cs)
grant_type=password&username=Alice&password=password123
After login, we recieve bearer token, which we need to send with authorization header with every request to access protected resource.
As you are using awesome frontend framework AngularJs, you can save bearer token in local storage, and you can write a http interceptor service, which takes care of sending bearer token with each request.
Here registering the user is taken care by Asp.Net identity, where as authenticating user is taken care by OAuthAuthorizationServer which is present in Providers folder by default.
Bearer tokens, that we recieve are not towards a specific client,so any one can intercept them. So use them only over SSL.
Please go through this links
http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
http://bitoftech.net/2014/06/09/angularjs-token-authentication-using-asp-net-web-api-2-owin-asp-net-identity/
Vs2013 webapplication project template comes with a good owin setup. I suggest to look into that
I have spent quite some time now looking at the Windows Identity Foundation. I even read a few chapters of a book on it on MSDN.
But I'm still confused about one thing. Is WIF appropriate for a public facing web site authentication or is this mainly targeted towards intranets/sharepoint sites, something that deals with internal domain where users are identified by integrated windows auth/active directory or something like that. Currently, we have many web sites for our company where people log in and are authenticated against a data store using forms authentication/custom asp.net membership provider. Is it possible to replace this mechanism with WIF? if so, does anyone have a link to such a tutorial.
I have tried looking for any information along these lines but it has been hard to find.
In principle, there's nothing about Windows Identity Foundation that makes it inappropriate for use on a "public-facing" website and WIF isn't in-itself tied to a particular authentication mechanism either. However, if you were considering using Active Directory Federated Services as your Identity Provider the problem would be that authenticating users against AD would be your only option since that's all it supports (although you can plug in a custom attribute store that retrieves claim values from some other datastore). Your WIF relying-party (i.e. your website) doesn't necessarily care how the user was authenticated, though, only that they were authenticated by an IDP that it trusts.
So your problem might not be that of "WIF-enabling" the websites as such, it may be more a question of finding a compatible IDP that supports authenticating against something other than Active Directory so that you can use the data store you currently use to authenticate users. It is possible to use ADFS as a "bridge" (a Relying-Party Security Token Server) between your WIF relying party and a SAML2 IDP like Shibboleth which can use a database to authenticate users, but configuring such a system is a significant challenge so you'd have to weigh up the benefits that your users might gain from single sign-on to your applications against the considerable effort it would take to set up and maintain such a system.
Yes - WIF appropriate for public facing web site authentication. ADFS v2.0 only authenticates against AD. However, you can write a custom STS that authenticates against anything you like. In your case, with a data store, have a look at Identity Server which authenticates against a SQL DB.
Have a look at:
http://claimsid.codeplex.com/
Identity Training Kit
How to: Build an ASP.NET STS