We have created an SSO solution using IdentityServer4. Our public/affiliated users are authenticated by an account stored in a database and our corporate/internal users are authenticated using their Active Directory accounts.
The problem we're having is that when we host our IdentityServer solution on a DMZ (not on our domain) it cannot access Active Directory (on our domain) to verify a user's login credentials and roles/claims.
My goal is to know the best solution to this problem.
Is the best practice to implement Active Directory Federation Services?
Do we need to host IdentityServer on our domain so that it has AD access and then create a second application to host externally and call in to our actual IdentityServer?
Is there a secure solution our networking team can implement to allow the external server to access AD on our domain (ie: somehow grant AD permissions to the IIS Application Pool Identity)?
At a bit of a loss on what the best practice is here. Not sure if this is a problem for our networking/operations team or for our development team.
Thanks in advance.
IdentityServer4 supports to deploy UI (Login Pages) as a separate application. So one solution is to have UI in DMZ and other BE server in Domain.
In all other cases, you will be providing Database Access to a Server in DMZ (which is not supposed to be best thing).
Related
I have a website (azure), that has a login page for the user to insert it's username and password.
Currently, the login is using LDAP to autenticate the user.
Now the client wants to use/activate the single sign on functionality, but using their Windows Server Active Directory (they don't want to use the Azure Active Directory).
Is this possible to do? Whats the best approach?
These are the two options I know:
You can use Microsoft Active Directory Federation Services (aka ADFS). This is a component that should be installed in your customer infrastructure and talks with the AD, your website will talk WS-Federation with ADFS. Authenticating a user means basically redirecting the user to a ADFS, if the user is in the LAN and is already authenticated to AD, ADFS will login automatically, but if is outside it will prompt user credentials.
Another approach will be to use a third party authentication broker. Auth0 is an authentication broker that you can add from the azure store, you will need to create an AD "Connection", which will require to install an small MSI on your customer infrastructure. For this case it works more or less like ADFS but your application talks OAuth with Auth0 rather than Ws-Federation so in lot of cases it is easier to implement.
Disclaimer: I work for Auth0.
I am wondering if anyone has faced a similar issue. We are working on enterprise client portal that would be sitting on the internet. We also would like to add managements/client services portal that would be sitting on the local network and would use the same core libraries. For the external clients we would like to use forms authentication and for the internal application we would like to use windows authentication. Right now we are leaning to use sql membership provider on the external site and active directory membership provider on the internal site. We are working with mvc 4 so we use claims principal throughout the app.
The questions are:
1. Is there a way to combine users so we can enforce username uniqueness using existing providers?
2. We are considering using user email as the key. Is this a security issue. Can I get user email from AD membership provider?
I have looked into simplemembership provider. I thought that I could utilize webpages_OAuthMembership table to store "LDAP" users. But there is no oauth provider for that so I would have to write our own.
On another hand it seems that simplemembership is just a temporary solution until ASPNET.Identity come out in Nov.
Do you have any suggestions?
Have you looked into Windows Identity Federation (WIF), ASP.NET Identity, MVC5?
All your cases can be implemented using above.
I am currently trying to understand the combination of Azure ACS with Claims-based Auth and the option of using a custom STS and I am only slowly getting through the (unfortunately few) info sources.
Before I spend more hours on this I would like to confirm if my plan is even possible.
I have multiple azure roles (web+worker) that are being accessed over the internet by both employees and customers. Additionally, employees access these roles and desktop apps from inside our local network.
User data comes from two sources. Our azure app has user data about customers and employees, our (local) AD only from employees.
To make the login experience as efficient (and ergonomic) as possible, when accessed via our local network, employees should be automatically authenticated (Windows Integrated Auth?) on both the desktop app (automatically because of Windows User Profile Context) and on the azure apps (hopefully w/o login page).
Customers, on the other hand, should enter their user credentials when accessing the azure app, but should not have to decide between different "Credential-sources", they should just get the username+password form.
In other words
Employee visits Azure app from local network -> Auto-login with Integrated Auth / AD data
Employee visits Azure app from internet -> Username+Password form
Customer visits Azure app from internet -> Username+Password form
While writing this question, two more came to mind:
1) Is it even possible to auto-login based on source/cookie/wizardry or would that require a manual user choice for selecting the "Credential-Source"?
2) If Azure ACS "knows" that AD account with Username X is the same as Azure App User Y, does it matter with which one logins? Can the app access the same claim-data on either login route?
Are you sure you need a custom STS? It sounds like to start you just want to enable your AD users to sign in to your azure applications using their windows credentials if they are on the domain (no password prompt). ADFS 2.0 and WIF will facilitate this. In addition, if you set up an ADFS proxy server so that when those same users browse to your app from outside of the domain they will get prompted for their domain credentials.
Now your AD users are set up, but if you want your applications to be accessible to users outside of your domain, you can federate ADFS with another organization's ADFS server, or use ACS to enable login using consumer identity providers such as Google, Yahoo, and LiveID, which are provided as built in options. If you did introduce ACS like this, you would configure your corporate ADFS server as an identity provider on your ACS instance alongside google, yahoo and what not, so that when your users browse to your site they will be prompted to select which identity provider they wish to sign in with.
Here's a fantastic whitepaper that demonstrates using ADFS to authenticate to cloud applications:
http://www.microsoft.com/download/en/details.aspx?id=13789
More detailed info about deploying ADFS (such as deploying the ADFS proxy) can be found in technet.
And for ACS, there are guides and samples on how to integrate it into azure applications, and how to add ADFS identity providers: http://msdn.com/acs
One thing that you could do is look at the user credentials when a page is requested in order to get the authentication info.
If you look at...
HttpContext.Current.User.Identity
You can get info about the user's identity. If they are on the domain you will see that they have a domain name and you could programmatically choose to direct them to a login page.
Let me also say that I've never tried to do this so I don't know if there's a built in way to do this by simply configuring something in web.config.
I have a web application using windows authentication. I also want to authenticate non-domain users against AD. Can I have domain members can enter site directly, and non-members enter their domain username and password.
How can I do this?
It is possible to do this but you probably want to have 2 distinct web applications running accessing a similar set of application code.
Web application 1 is configured to use Windows authentication.
Web application 2 is configured to use Forms authentication. You need to have some additional code in this application which allows a user to authenticate themselves using LDAP against the active directory. This code is placed in an authentication provider if you use ASP.NET.
Assuming your using ASP.NET, you can write a custom provider that first auths against your AD, then a non AD store.
Or you can use multiple providers, ActiveDirectoryMembershipProvider and then for example SqlMembershipProvider.
Our company is trying to implement a few single sign-on applications using Active Directory (Windows Server 2003) and LDAP. I would like to lock down the account used to make these LDAP queries as much as possible. What is the best practice for configuring this type of account?
You can restrict/allow what a user can or see/query within AD by easily using the Delegation Wizard. You can access the Delegation Wizard easily by right-clicking on an OU, and the selecting Delegation Control. You als may want to take a look at these articles:
Default security concerns in Active Directory delegation
Best practices for delegating Active Directory administration: How delegation works in Active Directory
Best practices for delegating Active Directory administration: Case study: a delegation scenario
Please see How to configure Active Directory to allow anonymous queries for minimum security.
By default, the Microsoft LDAP implementation does not support Secure LDAP. To setup secure LDAP using SSL, certificates must be installed on both the LDAP Server and the LDAP Client(s). In many cases, the LDAP Server is the domain controller running Active Directory.
The certificates required to run secure LDAP using SSL can be configured in several ways. The concept is always the same:
The Active Directory domain
controller uses a special certificate
that is issued by a trusted
certification authority.
The clent computer trusts the
certification authority that issues
the certificate to the Active
Directory domain controller.