I am designing an N-Layer system in .NET that will consist of
SQL Server 2008
EF 4
Repository Layer
Service Layer(Business Logic)
On top of this I will have:
ASP.NET MVC website
external API to be consumed by other clients(built with WCF or ServceStack.NET)
I would like to implement the typical username/password auth within the MVC app as well as OpenID/twitter/facebook login options
The api will need similar forms of authentication.
Where in the architecture is the best place to implement the authentication and are any samples available of how to implement something like this with a .NET Stack?
Is a custom Membership provider an option for this?
I realize that there are libraries available to implement the openID portion so that is not a concern at the moment but I would like to leave things open to add this in the future.
Suggestions?
Authentication should be done at the user facing point: MVC website and the WCF service.
In each point, use the appropriate authentication/authorization mechanism.
MVC website: forms authentication (or windows authentication etc.)
WCF service: (what method will you be taking, API key, user/name password on every request, secure key, auth cookie etc.)
For each point, call the service layer with the credentials used by the requestor (user) and validate it against your database (in the service layer).
The service layer should return valid/invalid for the credentials given to it.
If it's invalid, have your website or webservice reject any further actions from the user and inform them that it's not valid.
If it's valid, have your MVC website create the auth cookie (FormsAuthentication.SetAuthCookie) and your WCF service do the appropriate action for the authentication mechanism you chose.
Keep your service layer agnostic of the authentication. It should only respond with whether or not a set of credentials is valid and your front-facing layers should take care of setting the authentication tickets.
For Open ID/Twitter/Facebook logins, all the information needed is on the web app (via the login source cookies), so use that to setup your website's auth cookie.
A basic architecture would be to use the asp.net membership api for your service and web apps calling into the same membership database. Then use an impersonated user to connect to SQL Server.
You can then write custom membership providers for the other auth mechanisms or incorporate them all into one membership provider.
Sorry had to write this as another answer as didn't have enough space in the comments.
Configure the membership provider at the IIS level and use the OOTB SQL membership provider to get basic authentication working.
You can then write a custom membership the repository layer will be running in the context of the web application either web service or asp.net site so your authentication information will be in the httpcontext, you can then use that to connect through to your database or use an impersonated account i.e. the app pool user to connect instead.
You can then write a custom membership provider that authenticates against the other providers if you like and just swap out the standard SQL one for your custom one.
As an addition to Omar's answer:
You could also use a Facade Pattern which handles the authorization and is used by both the WCF and MVC code and provides the API to the business layer.
A rule of thumb is: Put authorization at one single point and let the auth-logic be handled by the client(s). Don't spread it over your service layer!
Related
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.
I currently have a web api 2 project acting as my applications middle tier. I need to secure this project as well as provide an authentication service for my MVC project and potentially iOS and Android applications.
The web api business logic requires the checking of the user permissions/roles to ensure security, the mvc project requires the same functionally to ensure the request to the controllers are valid. How do I do this using Asp.net Identity or some other means? Are there any reference projects for this sort of thing?
Some good info here:
http://www.asp.net/web-api/overview/security/authentication-filters
Another way I've seen it done is have a separate API to generate access tokens for a 'transaction' using whatever credentials you want to use...but usually done via https! This token is then passed by the client to the business layer API as a parameter. Various checks can be carried out on the token e.g. Same client that requested token? Token expired? Token already used? Etc
Let me know how you got on.
Thanks.
UPDATE
Web API Security with local accounts:
http://www.asp.net/web-api/overview/security/individual-accounts-in-web-api
Just like "Log in with StackExchange", I expect that StackExchange have a custom membership provider to be used for many applications.
I have many web applications, subjected to extend and i would like to have one database and a shared membership application to handle Login, Registration, profile and Role-based membership management.
After some research, I also found that using a WCF Service to handle this implementation would be a good idea.
I am just trying to get a feel of it before I go ahead with any application, and if there is any open source projects or even resources, I would prefer not to reinvent the wheel.
Could anyone tell me how could it be implemented?
There are several options available to you - the ASP.NET Membership Provider connected to a shared membership database, WCF Authentication Services, or OAuth.
ASP.NET Membership Provider
This doesn't have to be a custom membership provider - the standard SqlMembershipProvider model will cover your requirements, as long as each site can access the shared database. See here : http://msdn.microsoft.com/en-us/library/ms731049%28v=vs.110%29.aspx
WCF Authentication Services
If connecting to a shared database is not an option, then yes, WCF Authentication Services are available to you. WCF already gives you lots of pre-built code, so you wouldn't be reinventing the wheel. See here for specific code examples:
Walkthrough: Using ASP.NET Application Services
How to: Enable the WCF Authentication Service
How to: Customize User Login When Using the WCF Authentication Service
How to: Use Non-default Membership Provider for WCF Authentication Service
How to: Customize the Authentication Cookie from the WCF Authentication Service
OAuth
OAuth is a big topic, and a big opinion splitter. Have a read of this introductory article on MSDN. You may also want to consider a pre-built .NET OAuth library - see this one : http://oauth.net/code/
i am developing an applications which uses ASP.Net MVC 4 (.Net 4.5) and self-hosted websockets. For the user-handling and login-process i use the default asp.net mvc formauthentication system.
Does any one have an idea, how to share the login-session between the IIS (ASP.Net MVC) and the Windows service?
Thank you!
If you have several applications that all require same user to be logged in, then you need to implement a security pattern called Single Sign-On (SSO).
This requires that you have a centralized place where your authentication is done, and that place is called Security Token Service (STS) or Identity Provider (IdP).
When user attempts to access either your MVC application or your websocket endpoints, your authentication logic in application must redirect him to STS. STS will then require credentials, and based on those it will issue a Security Token. Client will then return to application that has caused a redirect and carry token with it. That token can then be used on any other application in your realm and as long as it is valid (not expired), security session is valid/shared on all your applications.
I'd suggest that you read about Windows Identity Foundation (WIF) 4.5 and SSO patterns, as some of the things mentioned above come out-of-the-box with WIF.
I have an ASP.NET web application I built for a client that uses default the ASP.NET forms authentication. They are now requesting a desktop (WinForms) app that works "with" the web application. I have created the webservices to access the data they want from the web app and put it into the desktop app. That works great.. but there needs to be the same level of security and data access based on roles that is already stored in the asp.net application.
So now it's time to make authentication work across both applications.
I would like to take advantage of the asp.net authentication by prompting a login when a user first opens the WinForms application and the calls possibly a web service to authenticate the user, get the users role, and profile.
I'm sure this has done and or asked about.. I'm just not finding the question/answer in SO.
First: Use WCF for your web services. It's a better framework than the old ASMX services.
Second: WCF can utilize the same RoleProvider and MembershipProvider classes that your ASP.NET application utilizes. It's a simple configuration switch. Use them both and your web service requires the same credentials as the web application.
And... that's pretty much it.
For more info, see:
Implementing a Role Provider
Implementing a Membership Provider
How to: Use the ASP.NET Membership Provider
To add to Randolpho's answer: another feature users might like is the ability to save their credentials rather than entering them every time they start your application. You can use the Credential Management API for this as described in this answer.