There is a requirement to implement Single Sign On (SSO) in our website so that users accessing it from the intranet won't have to type in their credentials.
The problem here is that the website is going to be hosted on the internet, on a remote server.
Is there some way this can be done?
--EDIT--
I looked at following link:
http://en.wikipedia.org/wiki/Active_Directory_Federation_Services
And the example scenario that is mentioned in there is exactly what we require.
Here is the detailed explanation on the situation:
There is an Active Directory Domain Controller that is used to authenticate users in the intranet.
Once the user logs into the machine, and opens up the remote website, the website should somehow verify that the user is already logged into the intranet using AD credentials and automatically allow access to the website.
Also, the website is supposed to be getting a Security Token that can be used to authenticate the user.
Of course, for example, Microsoft's way of doing that for connecting Office365 to your Intranet is called Active Directory Federation Services.
It is (as most single sign on solutions) not entirely straight forward, and it assumes a domain on your intranet, but since Office365 uses it, it is and will most likely continue to be well supported in the future.
It's just a matter of integrating your web app with the authentication provider that you are using for SSO. The details are going to vary dramatically if your using OAuth vs. Shibboleth vs. ADFS vs. etc, so there really isn't enough information in your question to give a helpful answer.
Related
I've been tasked with seeing if we can give users of our internal web application help links to documentation pages on our company's Confluence Wiki. But here's the problem, the requirement is that users should not have to log into Confluence because otherwise they won't bother using the help links (which is understandable). Is there a way to forward a user to Confluence and log them in with their current windows AD credentials? Every example of their api involves you supplying a username and password. We can't have that. If they are logged into our web app with their network cred, they should be able to see a page on our Confluence Wiki w/o logging in again.
Is this possible/practical or should we just use our own help docs system?
Note - when I log into our Confluence Wiki I use my Win AD credentials, so the two systems are connected. I just have no clue how to send a user and their credentials to their system from my asp.net webpage.
Thanks.
You want to configure your Confluence server to accept NTLM Authentication. I can't find the specific directions for Confluence, but given it shares backend code with Team City, you might find these directions helpful: https://confluence.jetbrains.com/display/TCD9/NTLM+HTTP+Authentication
At the very least hopefully this helps you find what to Google next.
By the way, You don't want to setup your website to forward credentials. It is possible, but your scenario is a simple website redirect. Credential forwarding would be if your are trying to talk to the server as an application server (and even then generally to be avoided).
While developing an on-premise, intranet-only REST API server for my company, I managed to completely confuse myself regarding authentication issues.
I have:
A REST web server implemented in C#, using self-hosted Nancy, running as a Windows Service
A C# client that can query the server, run by a user in our company
I do not have:
Any form of access to our Active Directory and/or domain controller, apart from what any application running under Windows normally has
Any way to influence AD settings or configuration
Active Directory Federation Services (ADFS) (I think. We use Windows 7 and Office 2010, just to give some perspective on the state of the software landscape)
Azure Active Directory (AAD)
I want:
A way for the server to authenticate that a request is made by a user of our company
It is perfectly fine if the client has to sent some additional authentication data with each request, as long as it does not contain the user's password in any form
I do not want to:
Have to set up any additional software (my server must be minimum configuration and maintenance, so the average user can install and run it)
Install / configure / maintain an IIS server (see above)
Use ASP.net (way too big for my needs, plus see above point(s))
Handle user passwords in any way (company policy and common sense)
Impersonate the user (I only need to validate the authenticity of the request)
Implement my own user account database. We already have half a dozen services that need their own username/password combinations, I do not want to add yet another one
I have read articles that show how to use Windows authentication with IIS, or how to use Azure Active Directory (AAD) with Nancy. Other questions here have already informed me how to authenticate username / password combinations against the Active Directory. However, none of these satisfy all of my requirements or have requirements of their own (like AAD/ADFS) that I cannot meet.
It seems that Kerberos/SSPI might be what I want, but it seems very involved and quite complicated to get working with C#. It is possible I will have to go this route, but I could really benefit from some minimal working example (the accepted answer provides a C# implementation/wrapper, including an example project, but I can't seem to be able to make heads or tails of it).
Maybe I am naive, but what I image the solution to be is something along the following lines:
The client queries a service (AD, Domain controller, ...?) for some form of authentication token, using the credentials of the currently logged in user
The token is then sent to the server together with the username, as part of the request that needs to be authenticated
The server extracts the token, and queries the same service (AD, Domain controller, ...) whether the token is authentic, valid and belongs to the user in question
Is this possible at all? Ideally, with some sort of ready made library that I can plug in to my projects (I'm reaching, I know)?
You can do this with stateless authentication and Jwt. Send a username and password to "/ auth" (example) and "/ auth" will search the AD (example) and validate if the user exists, then create a Jwt token with the name of the user on load. When you make a request, you will only send a Jwt token and Nancy validates the token.
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 web application (ASP.NET/C#) that our clients' employees use, and one of the authentication methods we support is an external Active Directory via LDAP.
I recently had a request to support Kerberos with AD.
What does this entail from a development perspective? I know the basics of Kerberos in the Unix world, but not sure how it fits in with AD/LDAP
Currently, I use standard LDAP to bind with a service account to find the user, then bind as that user with their provided credentials to verify the login.
What is needed differently to support Kerberos? My Google-fu is failing me.
To make it clear, the application server is not in the same domain as the AD server.
EDIT:
Is it even possible to do Kerberos authentication over an internet connection?
Greg here is what you would need to look at.. if you need help with any code samples let me know.. I currently work in Active Directory Group and have 8+ yrs experience coding in C# for AD and LDAP
you should still be able to validate user credentials if they sit on 2 different domains you want to look at the following PrincipalContext, 'UserPrincipal', 'GroupPrincipal if necessary', and ValidateCredentials which is probably the one you want the most
Kerberos has been standard in Windows for more than 13 years (since Windows 2000). All you need t do is enable Windows Auth with SPNEGO/Kerberos in your IIS. If you have a fat client, you can use SSPI to obtain a security context and read the currently logged in Kerberos UPN from. I have answered that kind of question already several times on SO. Please search.
Ok, I have looked around and could not find a solution to this problem. I have an ASP.NET web application that is using Windows Authentication.
I have a public web services that I use for an iPad App I have developed. For security reasons all of my Web Services requires a header with login information.
Right now, I have a separate database that I authenticate users from. Its a built in authentication for when my application is installed using Forms Authentication.
What I would like to do is when the user on the iPad logs into the system, it passes the Login and Password to the Web Service in the hearder... which it does now.
But, how can I Authenticate that User and Password against the Active Directory to make sure the user has access?
Thannks,
Cory
But, how can I Authenticate that User and Password against the Active
Directory to make sure the user has access?
That's straightforward in c#: Validate a username and password against Active Directory?
More AD tasks in c# (including authentication)
Right now, I have a separate database that I authenticate users from.
Its a built in authentication for when my application is installed
using Forms Authentication.
Based on this statement, it sounds like you have a database of credentials which duplicates credentials in AD? If that's the case, not sure that's a good idea.
And/or it also sounds like credentials which match those in AD are being passed around (possibly in plain text?) This might be a business requirement, but I would recommend that all communication is done over SSL and that the AD accounts belong to a domain setup specifically for this purpose that is not trusted (or only partially trusted) by the rest of the network.