How can I combine an ADFS based and a user database based authentication methods into a single process or at least result in a single User object with claims and roles so I can use AuthorizeAttribute?
I have two ASP.Net MVC applications that I need to combine into a single application, we're eliminating duplicated functionality. Normally this would be a snap, but this one isn't. The problem is the user authentication App 1 uses ADFS and our AD accounts for authentication. The other application (App 2) uses a user database with salted and hashed passwords. Not all users in App 2 have, and will never have, AD accounts. That is corporate policy and not negotiable.
In another application I was able to add additional claims to the User object for dynamically named claims and a custom AuthorizeAttribute. I'm sure I'll need to perform the same action on the App 2 accounts, but I'm not sure how to integrate the two styles seamlessly.
Probably the easiest way is to use identityserver 4 to handle the DB authentication and then federate ADFS and identityserver.
Or use a SaaS Identity provider like Auth0 for the DB side. Then federate ADFS and Auth0.
Related
We have built some Asp.Net Core web API, with the authentication/authorization built on top of Asp.Net Core identy, with some JWT token exchange for our angular frontend. Basically, the users can login with username+password, this provide them a JWT with a short validity that the frontend regularly refresh. If the token is not valid anymore, the user will have to login again.
This part works great.
Now, we have to add another concept, a bit like on Azure Devop, we need to add "agent", those are not users, they will just need to be authenticated, in a slightly different way:
They will run on unnattended(locked) computers
They will be configured once and then run forever
Each agent should NOT be considered as a user. They should not be stored as such(or at least provide a way to distinguish them)
Those agent should only have some kind of token/private key to authenticate themself, that doesn't expire. This method of authentication should not be allowed to other users
So based on this:
Is this something that already exists, or have this pattern a name?
Is there a way to achieve this through Asp.Net Core identity or am I better off ?
Any link or lead on how to implement in parallel of an existing auth would be highly appreciated.
I want to implement authentication and authorization in my application. I am developing my application using AngularJs and ASP.NET Web API.
I want to achieve:
Its an intranet application and want to use windows authentication.
For Authorization, we want to maintain a table in database with username and role column and using this table we will be authorizing users.
Please suggest how could I implement this within my application using AngularJs and Web API.
Set up your WebAPI libraries to use Windows Authentication. Add your [Authorization] attributes to your controllers. Your startup logic can certainly pull role names from your database and add those roles for use in the [Authorization] attributes on the controllers/methods.
I don't know that I'd do this on a per-username basis though - I'd create some roles (e.g. admin, user) and control those through AD if I was using Windows Auth. I'd then just store the AD group names as my role names.
Angualr.JS doesn't really factor into the picture much at all here - the auth will be handled by the browser. The one thing you may want or need is some way to get the user name from the User object in the API layer - in other words, creating an API method to return information about the logged in user (including that user's name, which won't be managed by the Angular.JS application as it might be if you were using some other form of authentication).
I have an Owin-based MVC application which uses my web api to provide many functionalities. At the moment the user should login to both of them separately (using ajax calls, at the login page I do the login for web api and receive the token as well), but both use the same table, so there is only one place to store the user information.
Unfortunately other MVC applications are using separate username and passwords and are not using the mentioned api. As now I should create a new MVC app which is again the same domain I am looking for a way to use a single username and password (managed by one main MVC app) for whatever reason it's needed, i.e., all the MVC apps and the web APIs use the same username and password, and therefore for example I can use the [Authorize] attribute or roles, ... in all of them.
Is there any known solution for this? Does Creating an OAuth authorization server suit this problem?
Implementing Single-Sign on using OpenID Connect on top of OAuth2 fits your requirement. checkout identityServer3 or identityServer4 if you are using .net core.
basically, you will need to setup a shared STS authority, and all your applications will use this authority to validate a requests using a OWIN middleware to check for token validity.
On first login, The STS authority will issue a token for the user, and you will need to manage through your front-end/back-end code, re-using the token when navigating across multiple applications/domains.
C# ASP.NET Single Sign-On Implementation
We have an ASP.NET/MVC website that's using FormsAuthentication. As is usual, when the user tries to access a page, and doesn't have a valid FormsAuthentication cookie, IIS redirects him to the login view. When the user does a HttpPost to the login controller, our controller action makes a call to our WebApi webservice, which validates username, password, and customerid against a Sql Server database. If the authentication passes, the controller action sets a FormsAuthentication cookie, and redirects to the page the user had asked for.
Now sales is making noises about "Single Sign-On", though I'm not clear exactly what they mean by that. From what I've read, in the Microsoft World this usually means accessing MS's Active Directory Federation Services.
At this point I have almost no idea how this would work, but before I dig into this too deeply, would it be possible to put the authentication code within the WebApi webservice, where we could choose to validate against the Sql Server database, or against whichever ADFS server was appropriate for the specified customer?
Our problem is that we have I don't know how many thousands of users, working for some hundreds of customers. Many customers will not have ADFS running, and those who do will each have their own ADFS server.
Most of what I see with respect to Single Sign-On seems to involve doing browser redirection to the ADFS server, then redirection back, and looks to be avoiding login at all, if you're already logged in. I don't think we can do that, in our case. We can't know which ADFS server to redirect to, until we hit the database.
So, the question - is it possible to do ADFS authentication entirely from C# code in our WebAPI web service?
(One possible complication - the website itself has zero access to any database. The sole configuration setting in its web.config is the base URL of the webservice. Whatever authentication happens has to happen in the webservice, not in the website.)
First of all, "Single Sign-On" (SSO) is not limited to ADFS. It simply means that you type your credentials only once, and then all systems you access automatically "recognize" you; all subsequent authorizations request are transparent. For instance, if you have several web sites using Windows Authentication in your company Intranet (same AD domain), you have SSO: you authenticate once when you log in to your computer, and then your web browser authenticates automatically to these web sites using NTLM or Kerberos. No ADFS in this case.
What ADFS (and "Federation" more generally) allows, is SSO accross security boundaries. In Windows world, a security zone is typically created by an Active Directory forest; everything within this forest is accessible using SSO provided by Windows authentication. But as soon as you leave this zone (SaaS application, web site in another company network), you need another authentication protocol to perform SSO, and these protocols are implemented in ADFS.
Then about your particular problem:
What you could do is instead of using FormsAuth, you use AdfsAuth. When a unknown user accesses a page, he would be redirected to ADFS for authentication (using browser redirects as you correctly mention). To know which ADFS server should authenticate your user, you need a way to differentiate them indeed: a list of IP range per customer? a different URL per customer? If you don't have something like this, then the only way is to show them a list of choices such as: "I work for CompanyA", "I work for CompanyB", "I work for CompanyC", "I don't work for any of these companies and want to authenticate using FormsAuth."
In this case, what your WebApi web service has to do is: if I know which ADFS server to use, redirect the user there. Otherwise authenticate the user as usual using the database.
When you use AdfsAuth for a customer, your database is useless. You can delete all credentials related to this customer.
do ADFS authentication entirely from C# code in our WebAPI
Well it's possible to "re-implement" ADFS in your service, but you won't get SSO if you do that. When you use federation, your redirect the user to the ADFS server of his company. This ADFS server is in the same domain as his computer, so the user gets SSO here. Once again, your users can't get SSO if you authenticate them yourself, because your users are not in the same security zone as your site.
When authenticating to multiple identity providers, it is typical redirect to your own STS. So, in this case, you would have www.yourapp.com redirecting to sts.yourapp.com, which redirects to sts.somecustomer.com.
The specific tools to enable such a dataflow is the home realm parameter (whr), and the AD FS Powershell API (to allow IDP maintenance).
Your RP-STS acts as the trust-point for the app, and manages selection of the appropriate IDP. One RP-STS, many IP-STS's. Each of your Customer's IP-STS gets set up as a Claims Provider Trust in AD FS.
As always, Vittorio has already covered the subject better than I could.
I have a SaaS web application that caters to multiple education institutions. All clients are hosted in the same application/database. The application is currently written in C# for ASP.Net 4 Web Forms.
Currently my application uses a local/native database for user authentication/authorization.
Our clients are asking us to support single-sign-on where the client is the authentication provider and my application the consumer.
The problem is that the clients are asking for SSO via different protocols/mechanisms like Shibboleth and OpenID Connect. This means I need-to/should create a solution that works with all of these or that is at least extensible.
I came across Thinktecture's IdentityServer, which I think can abstract the various SSO mechanisms used by my clients and return to my app a claims based identity token that my app understands.
I'm struggling a lot with this concept though. Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user? How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)? Does the IdentityServer need to validate the existence of the user in my app's local/native database? Can the IdentityServer handle both SSO and local logins?
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server). But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it. ADFS may provide a similar solution, but most examples out there speak to ADFS and Azure.
Lastly, I'm assuming that I'll still maintain local/native authorization data about each user as the 3rd party authentication provider can't possibly know the specific authorization needs of my application.
Any thoughts or suggestions out there?
Does this mean that my app redirects all authentication requests to the IdentityServer, lets IdentityServer handle the back and forth of say OpenID Connect, and then receives a token back from IdentityServer with the information I need about the user?
Basically YES. But it depends on how you set it up. Your page could call Authentication provider of the client if you have only one client or one authentication provider. Or you could set up your local IdentityServer (more extensible IMHO) and configure authentication provider of your client as another IdP (identity provider).
How does the identity server know the realm of the user (i.e. so it knows which client auth provider to send the user to)?
If you go with the second option then your app will redirect to IdentityServer and based on home realm it will be automatically redirected to IdP. If no home realm is specified by your application then IdentityServer will show all configured IdPs and user chooses what IdP to authenticate at.
Does the IdentityServer need to validate the existence of the user in my app's local/native database?
It depends on you. If you wish to verify the existence of the user in your local database then you may do so by extending IdentityServer.
Can the IdentityServer handle both SSO and local logins?
Yes, it can.
Is a separate identity server the way to go? It seems like it would be, allowing my app to integrate with one point (the identity server).
You can always use IdentityServer and integrate it in your local application. Or you can use Shiboleth as your local authentication provider. Both are implementing standards like WS-Federation, WS-Trust or OpenId and both are open source so you can extend/modify it to your liking.
But, there's not a lot of documentation out there on Thinktecture's IdentityServer other than how to configure it.
I can't really say how much documentation is there. But if you wish, NDC Oslo 2014 will feature 2 days of Pre-Conference Workshops where Dominick Baier and Brock Allen (authors of IdentityServer) will teach you everything you want to know.