I am working on creating a website for my web systems class in which I will be implementing a login platform. The website after becoming authenticated the user will be able to send messages to other users, I will be implementing SignalR to perform the real-time messaging.
I want to create a system that within AngularJS I can call a C# backend provide a username and password and authenticate. I would also at the same time like to use SignalR's role based authentication to ensure my methods are secure.
Example:
[Authorize(Roles = "Admin")]
public class AdminAuthHub : Hub
{
}
Currently I've written my own code to accept a username and password and hash it and store the hash value. However, I don't want to reinvent the wheel here. I want to use a Microsoft based authentication system because I am working within a C# backend and SignalR technology.
I am currently hosting using Microsoft Azure and that works and all but I am eventually going to be switching to a locally hosted Windows Server I maintain. I have heard about using Active Directory but have never worked with it and would have to do extensive setup to get a fresh server ready for that.
My overall question is what path do I go? Also if I go the strictly Microsoft everything way, is setting up active directory simple on Windows Server 2016? During my research I found that there is a ASP.NET method of authenticating a user against a SQL Server database. Would this method be preferable because the system can be used outside of ASP.NET and the data is in a form that I've worked with before?
Do I write my own custom authenticate logic, accepting username and password and hashing and using my own tables and databases. Then within the SignalR side of things find a way of setting the user variable and setting their role from my database. Then simply performing a check at the beginning of each method call.
There is a lot of information on the internet about how to potentially approach some of those questions.
A quick google for "Angualr / Asp.net identity / signalr" returns a few resources that you may suite your needs, maybe not solely, but you should be able to combine some of the approaches.
Here a few links for you :
SignalR Authorization using Web API Token
https://logcorner.com/angular-js-token-based-authentication-using-asp-net-identity-and-asp-net-web-api/
https://www.codeproject.com/Articles/884647/Web-app-using-Web-API-SignalR-and-AngularJS
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'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'm using the Novell.Directory.Ldap library to get communication between my intranet application and an Active Directory server.
However I need to implement an authentication where I verify if the user is authenticated in my local network and is part of a certain group.
All the user verification logic with the AD and if it is part of this particular group is already ready using the library mentioned above. However, I need this to work alongside ASP.NET authentication.
Has anyone implemented anything like this and can you help me with this?
I would like to add a password protected page to my WPF modernUI application and could use some help with it.
First of all I don't really have a clue how to handle this stuff correctly in my case.
My application is used on several machines. The protected page should be some kind of admin-page to edit a database that is used by the app.
My idea is, that there is only one Admin-account. But this account can be used from any machine. The admin should be able to change his password. So there must be some kind of encrypted password file on the server which can be accessed from any machine. I don't want to store the password within the application, as this would mean that the admin has to change his password on every machine.
So my question is: What is the best/safest solution for my idea? I'm just looking for hints as I don't have a clue what to search for.
The best Practise nowadays for distributed client applications who share a Database is indeed not to have direct access to the Database.
What you need is a WebService. A web service can be anything. It just has to be hosted somewhere. It can be an ASP.NET application, a WCF Service, or even something not .NET related like a PHP or Java application.
The communication between your application and your WebService depends on what you decide to use. Today a lot of people are using so called REST APIs which use either XML or JSON as data transfer format and use the HTTP protocol.
Its not hard to implement such an API since there are ton of Libs and Solutions out there.
You could use RestSharp for the communication at your client side. Which is straight forward and simple. You could also consume a WCF Service. Which is hosted in IIS somewhere.
However your Problem is nothing special and there are several solutions available. The decision is on your side since it depends on a lot of things such budget, available infrastructe etc.
Your question is quite broad but as far as WPF is concerned you could implement custom authentication and authorization in your application by creating classes that derive from the IIdentity and IPrincipal interfaces and overriding the application thread’s default identity. Please refer to the following blog post for more information an an example.
Custom authorization in WPF: https://blog.magnusmontin.net/2013/03/24/custom-authorization-in-wpf/
The actual credentials should be stored on some remote server that may be accessed through a web service, WCF service or some other kind of API. The details of how to actually get the credentails would be implemented in the AuthenticationService class in the sample code from the above link.
I am investigating how IdentityServer 3 works and I still have problem to fully understand.
In general concept is clear to me but still I am not sure how to implement this on real project.
This is basic example that I am trying to implement in my case: link
I have web api project and I want to call my api methods from any client (mvc, wpf, phone…)
So I need implementation that is suitable for all clients.
If I understand well (and probably I am not understand completely), I should have 3 projects:
Client
Api
Project that host IdentityServer
And all projects should have required stuff like on picture:
Steps on picture:
Get token
Return token
Call api
Check if Token is OK
If Token is fine than return data else show error
My questions are:
Is my thinking about how this works ok?
Where I making mistakes?
Is this example good enough for my case? Am I missing something
important?
Do I have to create project that host IdentityServer, or this is
needed just for example code ?
Does IdentityServer host project must be console application that
communicate with api and client(like in example), or in real world
this is done differently ?
Should project that host identity server be aware of Clients and
Users ?
Should some other project except host identity server project be aware of Clients and Users ?
What is diference between implicit and hybrid flow, what I need in my case and why?
How do I create my own login view? I want have html page for login if I use web client, but to have wpf login view if I use wpf, also different view for mobile client.
EDIT:
I think that I need Resource Owner flow . I supose that resource i view where user type user name and password.
Your basic flow is correct, with Identity Server acting as your authorization server and your client and web API separate.
You should host Identity Server in its own project to ensure it is separate from any other logic which has the potential to introduce security concerns. How you host it is up to you and your use case. Typically you would see it hosted within an ASP.NET project on an IIS Server.
Identity Server must be aware of clients and users in order to authenticate them. The only other projects that should be aware of your identity store (users) is any applications that concern things like admin, user registration, etc. The client store would only ever be used by Identity Server.
Views can be modified using the Identity Server templates or by introducing your own ViewService. See the docs for more info: https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html
Regarding flows, the Resource Owner flow is OAuth only, so there will be no authentication (log in page), only authorization (server to server).