Develop Reference

How does application validate the authenticated token from Azure Active Directory?

I have an application which is sitting behind WAF (Web Application Firewall).
Application is using Microsoft Active Directory for authentication.
Here are the steps
User try to access the application using the browser.
WAF layers see that REQUEST is not authenticated, hence forward it to Azure Active Directory
AAD shows the login page and the user enters username/password/MFA
Now token from AAD send back to the browser and it will be sent to the backend application
Now question is,
How backend application verify this token? Does it need an outbound connection to AAD or will it talk to AAD through WAF and browser?
Do I need to have NSG rules (outbound ) to talk with AAD?

It depends on which auth flow you are using.
For Authorization code flow, your application would need to talk to AAD to redeem auth code for access token and refresh token via back channel. So, you would need to allow connection to AAD (login.microsoftonline.com).
For Implicit grant flow, it's browser which directly gets access token from AAD via front channel. So, in that case, you won't need whitelisting in backend WAF.

I have resolved the issue by using service tag feature in NSG. Backend application need to be able to reach AAD in order to validate the access token.
I have added outbound rule with Destination Service Tag Azure Active Directory as shown below.
Here is the link: https://learn.microsoft.com/en-us/azure/virtual-network/service-tags-overview

ASP.Net MVC Web App can I / should I securely store 3rd party login details

We have an ASP.Net Web Application which we log into using standard Individual User Accounts.
Depending upon the users login, they are then also logged into a web service after the Web Application login has been mapped to the required Web Service login. It is not a one to one mapped login, the user could select to access any one of a number of available web services.
i.e.
Web App login JohnD is mapped to Web Service A using Employee login details;
Web App login FredF is mapped to Web Service B using Maintainer login details;
Web App login BarneyR is mapped to Web Service B using Visitor login details;
An administration module should allow the assignment of Web App login to Web Service login.
For Proof Of Concept we've embedded some Web service login details within the Web Application. This is obviously insecure and we need to store the Web Service login details securely somewhere, somehow, encrypted in SQL Server tables? encrypted in WebConfig?
What is the best way to securely store and retrieve the mapped login details? or a better way to perform this 2 step login logic?

You should never store login details in reversible format (can be fully decrypted).
If the login details is reversible by the server then hackers will be able to do the same to retrieve everyone's login information upon successfully stealing the DB.
Login information for your own site should be stored with one way hash + salted. There is no reason why you would use a lower level security for 3rd party sites.
OAuth with access rights should be the answer to your question since it doesn't require users to give your site full access to the 3rd party site. After your site gets compromised the 3rd party site's login info won't be effected at all. Users can break the link to prevent further damage to their 3rd party site's account without having to wait for admin actions.

Can OpenID Connect in IdentityServer4 Request Tokens from Client rather than generate internally?

I am trying to better understand the OpenID Connect protocol with IdentityServer4, and am unclear on where I can find the answer to this question.
I like the idea of the Identity Server providing a Bearer Token at the end of authentication that includes claims on who the user is, and what resources they can access. However, I am a little uncomfortable in storing what Resources a user may have access to within the Identity Server environment. I would like this Authorization piece to be authored at my client application. Is there any type of callback in the OpenID callback that allows IdentityServer to call the client and request Authorization Claims from the client directly, rather than piece it together directly?
As an example, I am working on a product that will require a user to log in using either Windows Authentication, Username/Password, or a Google Account.
This client application will be hosted in a cloud environment, and will be hosted in the same domain as the Active Directory Server.
My thought was to create an Identity Server solution that is hosted internally, and to create a Client application that is hosted in the cloud.
When the user logs into the Client application, they would be redirected to the Identity Server to log in. The Identity Server would be hosted in the same domain as the Active Directory Server, so if there were Windows Credentials we could log them in automatically. Otherwise, there will be a login screen where they can enter a Username/Password, log in with Google, etc.
Once the user has logged in, the Identity Server would return a Bearer Token (a JWT probably), that has their claim information.
I can foresee this one Identity Server being used by many different Client application, because it would intrinsically allow Windows Authentication. For this reason, I am hesitant to store all of the API Resources the user can access within the Identity Server itself. My fear is that if I add a new permission to my client application (like a Report Admin claim), I would need to modify the Identity Server to include that new claim. And if 4 or 5 clients all use this Identity Server, this could get to be a bit onerous.
Instead, I would like to structure Identity Server so that when a user logs in for a particular client, Identity Server will make a callback request to the Client Application asking for the Claims that apply to that user. That way, the Client Application knows and cares about the User/Claim mappings, not the Identity Server. If I need to add a new Claim, I can do that within the Client application. If I need to map a user to a Claim, I can do that on the Client application. I don't need to do this on the Identity Server.
Is this functionality that already exists? If so, what do I need to be looking for? From what I can tell, it appears that the mapping between the User and the Resources they have access to all occur on the Identity Server.
The guide I am following is this: http://docs.identityserver.io/en/release/quickstarts/1_client_credentials.html#defining-the-api
Thank you for any guidance.

The Identity claims are not supposed to be used for Authorization, in fact Authentication and Authorization are two totally different concerns.
I'd suggest you watch this video which explains why and also provides an alternative PolicyServer that would answer your questions (great talk from the developers of IdentityServer).

Can a website authenticate against multiple ADFS servers?

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.

authenticate user using active directory and get a token to be used elsewhere

We have the following setup for authenticating users. A wcf authentication service that is hosted as a windows service on a server machine. The client is a C# CAB based application that communicates with the authentication service and other services (auditing,..) as needed.
We want to give an option of using Active directory to logon to the application.
The steps that were proposed are as shown below.
Authentication service running on server
user opens application on client
machine and chooses login by AD.
application, uses the userName and
password to authenticate user
against AD.
application sends some token from
the authenticated user to the
authentication service, to get back
information about sql server and sql
db name.
authentication service uses token against Active Directory
and verifies that user is logged on
and authenticated and returns back the required sql information.
Are steps 4 & 5 possible without the client app needing to send the username and password to the server for authenticating against AD? I want to avoid as much as possible sending passwords on the network.

You can't do that with AD and a client only, you need to involve a service in the authentication mechanism. If I were you, I'd send the username and password to the authentication service, the client shouldn't talk to the AD directly at all. And if you need some SSO, you can create a token in the authentication service. AD doesn't issue tokens, only you can, or another, more sophisticated service, like ADFS.