I'd like to use IdentityServer4 for authentication in my ASP.NET Core MVC web application, but the user registration process seems awkward. Most web sites that require user registration don't redirect you do a separate site (e.g. Facebook, Twitter, etc.) to sign up if you're using local user accounts.
One solution is to host IdentityServer4 in the same process as my MVC client, but that is discouraged.
Are there any good real world examples of local user registration with IdentityServer4?
IdentityServer is for authenticating existing users, not really creating new users.
In our use-case, we have 3 projects playing a part:
The identity server
A protected API
An identity provider (aspnet core identity) project
Users are created by a call to the API, which creates the appropriate structures in the identity provider.
Our identity server makes calls to the identity provider when validating requests for tokens.
Our API uses identity server to protect the resources, and our identity provider to retrieve information we may need about that user that aren't contained as claims (permissions, for example).
In this way our identity provider can be shared across projects (one user base with different roles), and the Identity Server is purely for authenticating users. All user management functions belong elsewhere.
EDIT:
#peyman We're not doing anything particular ground-breaking: just using the aspnet core identity framework (http://odetocode.com/blogs/scott/archive/2013/11/25/asp-net-core-identity.aspx).
The IUserStore and UserManager are the main drivers of this. When a user is created they are assigned a role, which for us is based on which application requested the creation of that user. Our implementation of IUserStore is what will ultimately be called by IdentityServer when verifying identity, and the data provided is used by IdentityServer to build up claims. Our resource API is relatively simply protected using Policies for claim based authorisation (https://learn.microsoft.com/en-us/aspnet/core/security/authorization/claims)
Related
I have a requirement to create an admin UI where I need to list all users registered on IdentityServer to start assigning permissions and roles. This application internally uses PolicyServer, but as a superadmin user, I would need to see all users registered on IdentityServer. Here IdentityServer is responsible for authentication and the other application that uses PolicyServer is responsible for the authorization.
Which is the correct way to proceed:
1- This admin UI application should be connected to the same database that IdentityServer uses to get all the users?
2 Or should I need to extend IdentityServer on this way?:
http://docs.identityserver.io/en/latest/topics/add_apis.html
I followed this issue here:
IdentityServer/IdentityServer3#2607
but still, it is not clear for me how to proceed on the question above.
Well, the users database is usually provided by ASP.NET Identity, not so Identity Server.
I had the same issue and I went on to develop the admin Web app in the same host as Identity Server, thus using the database connection to get to the users (and the API resources, clients, etc.).
I argue that this is the simplest way to achieve what you want. And still allows you to provide a complete API on your Identity Server for external apps. I also did that (for scenarios where client apps are allowed to view/edit the user profile, for example). The API was built using plain ASP.NET Core MVC.
I'm working on setting up a new SSO application. I would like to use ASP.NET Identity as a database to store the users data. I have a ReactJs application hosted on Node.JS and a .Net Web Api2 application. I want to protect thsi Web Api 2 using Identity Server with users from its database. In further development I'm going to create a mobile application.
I'm able to create an asp.net identity database with some users and use Resource Owner credentials, but I have couple of questions if anyone could help:
Why is Resource Owner Credentials not recommended? My current workflow is to hit the api with client&user&password and obtain a token which I store in web layer and use in Web Api requests. Web Api validates the tokens and identify the user. I read on IS page that's not recommended then what's the recommended scenario to authenticate the user?
How can I create an authenticator for mobile? Should I create my own certificate issue, store it in database as a thumbprint and use access token for that?
Thanks
In short, Resource Owner requires the credentials to be passed through the application itself, also RO doesn't give you SSO. Here's a longer answer. The recommended scenario is to use hybrid flow with PKCE enabled.
Look up TOTP. I believe it is implemented in AspNetCore.Identity with some examples.
We are currently creating a SimpleSAMLPHP based SSO/SLO implementation for an existing application based on CakePHP to connect to an Identity provided and authenticate users with accounts on the identity provider. The existing users in the application will still authenticate with their local credentials and the application will keep its session management for authentication.
I need to therefore implement an application specific SLO Soap service which logs the users out of the application, if the user logs out from another application using the same identity provider.
My question: Is it possible to change the SingleLogoutService in the generated metadata to point to an application specific soap service, which in turn logs the user out from both the service provider and the application.
We finally decided to use a different solution for the problem. The SingleLogoutService which is provided automatically by SimpleSAMLPHP is responsible for deleting the SingleSignOn Session when the user is logged out from the Identity provider. The application then checks SimpleSAMLPHP's session when the user attempts to access a protected resource and logs the user out if the user is no more authenticated with the Identity Provider.
I'm currently trying to implement a multi-tenant Azure AD application that will use Microsoft Graph API's to monitor and analyze Office 365 "metadata" for members of the tenant domain. For example, the application might monitor One Drive user space over time. The architecture of the application will include an AngularJS SPA client along with a web application back-end. The idea is that the web application allows for both local registration (e.g. traditional sign up using an email address and password) in addition to Azure AD authentication. In the case of local registration, the user might be able to associate an Azure AD tenancy with the local account in the future, for example.
I'm struggling to understand how various authentication mechanisms should work. For example, I think that there should be two levels of authentication in the case of Azure AD: one authentication for the users of the client SPA, and another authentication used by the back-end for making continuous calls to the Microsoft API's, requesting refresh tokens, etc.
How might this architecture be implemented using the various Azure AD authentication scenarios Microsoft has already provided examples for?
If my initial inclination that I will have two applications registered with Azure AD (for example, the SPA registered as a native application, say, and the web application registered by itself), how will users allow access to both of them, and what would this workflow look like? In addition, what would the flow of user requests look like? The SPA would make a request to the back-end using its Azure AD token, but what will the back-end do to receive its authentication token and make calls to the Microsoft API's?
How might I best incorporate Azure AD authentication along with local registration into my application?
Generally speaking, you can associate your each user to his entity in Azure AD tenant in your backend server / database. As every user in Azure AD has several unique properties in the entity object. You can use the user's email or objectId as mentioned at Claims in Azure AD Security Tokens as the external column in your user table.
When your user authenticate your site via ADAL.JS, you can grab the access token in your backend server via the Authentication header. You can use the access token to request for the resources protected by Azure AD. And the access token is a JWT token, which you can decode directly to get the user basic claims as we mentioned before. You can retrieve the claim which you stored in your user table and match the special user registered in your server for requesting the resource protected by your self.
My legacy web forms app uses windows authentication to match up the incoming user domain\username against a custom user table. If they are registered the user Id is stored in a session variable and whenever a new shipment record is created by the user the shipment record is created with the session.userID (foreign key to the user table.)
In a nutshell mu criteria is:
Use windows authentication (no typing passwords)
Use bearer token's.
Persist the user id (primary key) from custom table to track user records etc..
Use Web api
Use EF 6
I would like to build a new Angular front end with web api 2.0 Entity Framework 6 but continue using my own user table rather that the new asp.net.Identity.
The main criteria for this intranet application was people didn't want to have to type user names and passwords, they wanted to just authenticate by the windows account. I cannot see any example of how to do this with Web API and bearer token. All examples are based around the Asp.net.Identity
I was planning on using vs2013 Webapi with the Windows Authentication Template but I am lost and cannot see any example's for Intranet apps where people do this.
I really like the idea of bearer token's and want to use then but with my own user table whilst ensuring that my user.id is used by EF when new records are created etc..
The method of authentication is determined by the web server hosting your application, not the application itself. I have done this several times myself for production-level Intranet business web applications. The setting(s) that make this happen is located in your application's web.config file. Get to know the settings in that file very well. It's important.
There are two terms to keep in mind and both have different meanings: user authentication and user authorization. You don't need some fancy framework to accomplish user authentication, given your requirements. Since you are relying on Windows Authentication against Active Directory, anyone who isn't on your company's domain won't be able to access the website, period. The authentication is handled automatically for you by the server (IIS, I assume). It's super simple. When you provision the site under IIS, just make sure that Windows Authentication is the only enabled form of authentication.
User authorization can be more granular. Even though a user may be authenticated, you still may not want them to have access. This is where your user table comes in to play. The process is rather straightforward. Once the user is authenticated by the server, the server stores their credentials into the User.Identity variable that you can access in your server-side code. You could then verify that the User.Identity.Name is in your table and generate a verification token or cookie to store on the client. In the same action, you could also send to the client the user's id. I'd store the token and the user id either in the client's sessionStorage or as a cookie. Then, for security protection, you could send this token on every server request. As long as the token is valid, the HTTP action is processed. Furthermore, when the user makes a PUT, POST or DELETE, include the user id in the request data.
Here are some helpful links:
Authentication and Authorization in ASP.NET Web API
Integrated Windows Authentication
Web API Security