I am still learning the whole IdentityProvider, Authtentication, Authorization in .Net.
My question is, if I use Keycloak as my IdentityProvider is it a good idea to still create a User DB table then I'll just keep both KeyCloak and User DB in sync?
I tried doing some reading but still have a hard time understanding the concept
I don't think you can configure KeyCloak to use your SQL database. KeyCloak supports Kerberos and LDAP ("User federation") or Identity providers (Bitbucket, Facebook, Github, Google, twitter.. -> services, which support OAuth 2.0), which can be included e.g. via Open-ID or SAML. In the enterprise environment you often have HCL Domino or Microsoft AD, so you can use the ldap connection here. KeyCloak does not take over the data management itself but only uses identity sources that are connected. However, you can configure whether KeyCloak has read-only access or whether it can also modify data.
Maybe this article about Keycloak's core concept can help you further: https://developers.redhat.com/blog/2019/12/11/keycloak-core-concepts-of-open-source-identity-and-access-management
Related
I'm using AspNet Core identity for the authentication of my users. I want to connect to remote identity providers (Microsoft and Google). For Google, I think I'm fine with using Microsoft.AspNetCore.Authentication.Google (https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.google).
For Micorosft I have a couple of options, though:
Microsoft.AspNetCore.Authentication.AzureAD
Microsoft.AspNetCore.Authentication.MicrosoftAccount
Microsoft.AspNetCore.Authentication.OpenIdConnect
I was first using Microsoft.AspNetCore.Authentication.AzureAD. Then I switched to Microsoft.AspNetCore.Authentication.MicrosoftAccount. I was assuming that this would not have much impact but it turned out that now all name-identifiers of my users have changed. So, appearantly there are differences.
I find it not very clear what the pros and cons of the different options are. Can someone help me make a good choice?
Microsoft.AspNetCore.Authentication.MicrosoftAccount
This namespace contains types that enable support for Microsoft Account OAuth based authentication.
It Enables users to sign in with their existing credentials:
1)Is convenient for the users.
2)Shifts many of the complexities of managing the sign-in process onto a third party.
For more details refer this document
Microsoft.AspNetCore.Authentication.OpenIdConnect
This namespace contains types that enable support for OpenIdConnect based authentication.And OpenID Connect is an identity layer on top of the OAuth 2.0 protocol. It allows clients to request and receive information about authenticated sessions and end-users.
If you need to add authentication to an application and you want to use a third party as the authentication provider, then the recommended way to achieve this is using OpenId Connect.
Like Google or Facebook, OneLogin is also an OpenId Connect provider, which means that if you use OneLogin to store and manage the identities of your users, you can also use OneLogin to authenticate those users on your custom built apps.
For more details refer this document
Microsoft.AspNetCore.Authentication.AzureAD
The libraries Microsoft.AspNetCore.Authentication.AzureAD packages. As Per the document, since ASP.NET core 5.0, users should use the Microsoft.Identity.Web package to integrate with Azure AD and Azure ADB2C.
To migrate from Microsoft.AspNetCore.Authentication.AzureAD to Microsoft.Identity.Web refer this document
I'm looking to see if it's possible to use both individual user accounts authentication along side Azure AD authentication in a single application. Either Framework or Core (ASP.NET).
So far it's been all Google searching and I'm not finding anything that clearly states one can do this. Secondly, I'm not very familiar with authenticating an application aside from the basics for both individual or azure ad (well documented examples / VS template code).
Any help, links, small code example from Startup.cs is greatly appreciated.
Thanks.
It's too vast topic to put into an answer as a how-to-guide. However, I would try to give you brief overview and enough references/examples to look at. Your scenario can be better solved by using Azure AD B2C in conjunction with Azure AD. I strongly suggest you to go through the overview from those links for foundational concepts first. Azure AD B2C provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.
In your case, you need to add Azure AD as identity provider in the B2C tenant, and add required User flow (personal/social login) which will enable your user to login with either organizational (AAD) or personal/social account by signing up. This explains how to configure custom policies in B2C to add AAD as identity provider in such case. And for example, this provides you guide to enable Azure AD and Facebook login.
Now coming to code/SDK part, since you are into C# and asp.net, your one stop shop should be the new Microsoft Identity Web library. It would make your life lot easier to wire up with Microsoft Identity Platform with minimal configuration and code, and also has pretty good documentation, reference and samples to handle most common scenario. For example, this is a sample for B2C. There are many more here for your reference in case you need.
I would emphasize your starting point should be Microsoft Identity Web for asp.net core.
I'm making an app in Xamarin that requires login using local user accounts (not using any third party OAuth such as Google or Facebook) and I had previously worked with Devise for a Ruby on Rails app, and it's perfect for what I need here. I need to have a local (as in not hosted on a third party server) user database, email confirmation, forgot password, etc, and Devise was able to handle all of this gracefully. I have looked at Xamarin.Auth but it only mentions OAuth. Is there anything for C#/.NET/Xamarin that is functionally equivalent to Devise? I haven't found anything on Google, and the closest SO question I could find was this Authentication engine for ASP.Net MVC like Devise for Rails? but it's both old and it doesn't really provide any good solutions, and I was wondering if something may have changed in the meantime.
Since you're in the C# / NET stack, I would recommend Identity Server 4. It is an OIDC provider, you can also use it as classic authentication service using username/password.
You are looking for the Resource Owner password flow, which requires invoking the Token Endpoint of this service.
While I wouldn't suggest rolling your own authentication, sometimes there's a need for it. In that case, choosing a mature and standardized solution is the best way to move forward.
Identity Server 4 is an OIDC compliant, highly configurable and scalable .NET option.
I am trying to migrate one of our solution from a Laravel/PHP system to a .Net Core 2-based system. My main problem is regarding Authorization and Authentication.
I have 5 different apps that send REST queries to the Api (e.g. Web Browser, iOS Apps, Android Apps, etc.) and the way I currently handle authentication/authorization is as follows:
A user sends a Username/Password, as well as an App Id (e.g. 'Browser', 'iOS', etc.) and an App description (e.g. 'Chrome-Jacob', 'iPhone-7-Jacob').
If a Token already exists for the pair of App Id / App Description, it is returned. Otherwise, a new token is generated and saved in a Database table named 'Tokens'.
Each token can have a different matrix of permission, which is very granular (e.g. 'Users/ViewAll', 'Users/Create', 'Users/ViewOne', 'Users/ViewMe', etc.)
When a REST query is received with the token in the header, we look for the token's permission matrice in the database and try to see whether the intended feature to be accessed is authorised or not.
It seems that in Core 2, the intended use of token is through JWT. I'm not 100% comfortable with this approach, because I want the user to be able to see all tokens that were generated for his access, all associated permissions and the ability to simply revoke access to a token; whereas with a JWT, it is impossible to know who has what token, until they send it in a request.
My current implementation can generate any random token as long as it's unique in database; it doesn't necessitate any encryption algorithm.
What would be the best approach to replicate the system above in Core 2 ?
I find Microsoft's approach very good for simple applications but I am struggling to override the Authorize Attribute and get the granularity that I wish for.
I find Microsoft's approach very good for simple applications but I am struggling to override the Authorize Attribute and get the granularity that I wish for.
That's quite the opposite. Microsoft did not invent nor were close to the first to start using JWTs. You have taken something that is very common and made your own version of it, something that's not considered secure nor a good practice.
There are two ways to solve the problem at hand:
Using Identity Server 4, a free, open-source system made for ASP.NET Core, made by highly experienced security people, which provides you a customizable OAuth 2.0 / OpenID Connect system. With this, you would need to rework, some parts of the security of the applications, but you would be using industry standards.
Note: this might not be too easy, but scales extremely well
Identity server already gives you all the information about each application and which tokens are valid for which.
While you could do this by hand without too much trouble, I would suggest you to look at ASP.NET Core Identity, the official framework for Authentication and Authorization in ASP.NET Core. Notice that, regarding how to know which tokens/logins are active, Identity recently adopted two interesting tables:
IdentityUserLogin: tells you what users logged in where/how
IdentityUserToken: gives you the tokens that have been provided for a given user.
All this said, it's common to add ASP.NET Core Identity to an Identity Server 4 application, given that the later is not for handling authorization.
We need to make a central auth server for multiple applications that we build, while still having roles and claims which are specific to that particular application. Let me explain with an analogy using various services by Microsoft.
I sign up for a Microsoft account and hence my authentication info is stored in a central server. Now i login using the account and assume a fresh start i land up at account.microsoft.com, now i go to msdn click on sign in, it takes me to the login page on auth server then to the consent screen and back to msdn logged in, now i go to xbox and does the same thing. Now MDSN and XBOX are two completely different applications with each having it's own Api, web apps and mobile apps, but using the same auth server.
Till now i have been making independent applications using Identity Framework, and am reasonably comfortable with it, but this is comparatively much more complex than what i have done till now. I was looking through IdentityServer4 to have a central auth server and has completed all the tutorials present on the official doc site, so i have a basic idea of the concepts.
What i need is to have each application be able to specify it's own set of roles and claims without even having any kind of knowledge about other applications, and also the central server will be having external authentications enabled, hence ASP.NET Core Identity in central server.
Current Architecture
Central Identity Server (using IdentityServer4, ASP.NET Core Identity, Entity Framework)
One Central DB for Central Server
Multiple Applications Sets (API, MVC App, Xamarin Mobile Apps)
One or more DB for each application as per need
Things i am able to achieve till now
Customize an identity resource to get user claims stored in db but if i add one roles, it returns me the role repeatedly the number of times as the count of API resources and Clients
Alternate solutions that i came up in my mind
Store the claims and roles in application specific DB, but i guess that i will be facing these issues
too much effort wiring up the auth logic, as it will have to first get the identity from central server and then get claims from the application specific DB
not sure how i can do it using asp.net identity on client side
unused table on central auth server
duplication of auth logic across applications
These stack overflow questions gets the most closest but are not the exact solution
ASP.NET Core Identity and Identity Server 4 - [Roles, Claims and
IdentityResources]
IdentityServer, Claims and Roles
How to add additional claims to be included in the access_token using ASP.Net Identity with IdentityServer4
Any guidance that takes me in the right direction will help
EDIT #1 : It seems like someone has flagged this questions as off-topic, so just want to clarify that i am looking for a specific code/solution using identity server 4 and asp.net core identity and not some recommendation, though any guidance apart from the answer is welcome for better clarifications and understanding, but just the code would suffice, and i feel that it's as per the guidelines of the community.
EDIT #2
I tried doing authorization on client side as suggested by #travis.js but i am unable to understand how do i implement the claims on client side something like [Authorize(Roles="Admin")]
I think your alternative solution is the "right" one.
Addressing your concerns:
too much effort wiring up the auth logic, as it will have to first get
the identity from central server and then get claims from the
application specific DB
Sounds like exactly the right amount of effort to me. The Central Server does authentication and each app does its own authorization.
not sure how i can do it using asp.net identity on client side
You don't really need ASP.NET Identity on the client/app side. Identity is handled by your central server.
unused table on central auth server
Non-issue. But you could still use that table for its intended purpose just at a more macro level.
duplication of auth logic across applications
This does not sound like a duplication of logic. The Central Server does identity/authentication and each app is responsible for determining its own authorization logic.