We provide a hosted web application for multiple companies. Now we see the need to provide the ability for uses to 'auto login' if the are already logged into/identified by their individual local domains. What would be the best solutions for this? Would it be to have a certificate associated to their local AD account that our web application knows and therefore can identify and logon the user?
Any thoughts how to go about this?
This need to be implemented on a ASP .NET MVC application. Any examples greatly appreciated :-)
Cheers,
Tommy
What you've described is really a textbook example for using the new "Geneva" claims-based identity framework. The idea is that your server establishes a trust relationship with each of your users' companies. Each company would set up Active Directory Federation Services, which would issue a claim to your application when the user attempts to access it. Your application, using the Windows Identity Framework would check the claim comes from a trusted party, then extract the user's identity from it. It is all explained in AD FS 2 Federation with a Windows Identity Foundation (WIF) Application Step-By-Step Guide.
This approach will have much less of a maintenance overhead than using certificates.
Related
I'm using the Novell.Directory.Ldap library to get communication between my intranet application and an Active Directory server.
However I need to implement an authentication where I verify if the user is authenticated in my local network and is part of a certain group.
All the user verification logic with the AD and if it is part of this particular group is already ready using the library mentioned above. However, I need this to work alongside ASP.NET authentication.
Has anyone implemented anything like this and can you help me with this?
I am attempting to migrate an existing MVC application authenticated with individual accounts to be authenticated using Single Sign On with On Premise authentication from our corporate Active Directory.
I have seen several great walkthroughs for initial setup of On Premise authentication, but no good ones for migrating an existing application. I found this (Gareth Oakley) article, but it does not seem complete.
Do you have any suggestions of articles or instructions about how to migrate an existing application's authentication?
Thank you for your time.
I'm currently working on a project which has an authentication requirement which is causing me some problems and I'd like some guidance on the best way to achieve it.
I have an internet C# MVC 5 project which currently has OWIN cookie authentication in place for external users. We now need to allow internal users to be able to access the application through Active Directory. Basically, an internal user would log in to their Windows computer, navigate to the website and they'll be signed in.
I don't have any experience of doing AD authentication, so it's a bit of a black hole at the moment.
I'm assuming, using OWIN, I need to create a new authentication middleware that can run before my cookie authentication.
However, I'm not sure where to start with setting this AD middleware up, or whether there is an existing one I can use.
I've tried searching around but can't seem to find much information on doing AD authentication through OWIN, there's just a lot about Azure AD.
I did come across this one https://github.com/MohammadYounes/OWIN-MixedAuth, but running locally, it's using Windows basic authentication, perhaps this can be adjusted for my purposes?
Could someone offer some advice on how to achieve this?
Thank you!
I was facing the same problem not-so-long ago, and went the route to use NTLM authentication (which boils down to what you want, intranet users will be "signed-in" automatically) while keeping full application accounts (ASP:NET Identity 2.0), you may want to check my OWIN NTML authentication middleware:
https://github.com/pysco68/Pysco68.Owin.Authentication.Ntlm
You will need to add a route to you "accounts controller" to handle the sign-in with NTLM and the creation of a local application account (if required). As a comfort-feature you could add an automatic redirect to that sign-in route for users from your intranet.
I hope this helps.
The link you came across is using Integrated Windows authentication NOT basic authentication.
I think your situation is similar to this one. The same can be achieved using OWIN-MixedAuth as per this comment.
I have spent quite some time now looking at the Windows Identity Foundation. I even read a few chapters of a book on it on MSDN.
But I'm still confused about one thing. Is WIF appropriate for a public facing web site authentication or is this mainly targeted towards intranets/sharepoint sites, something that deals with internal domain where users are identified by integrated windows auth/active directory or something like that. Currently, we have many web sites for our company where people log in and are authenticated against a data store using forms authentication/custom asp.net membership provider. Is it possible to replace this mechanism with WIF? if so, does anyone have a link to such a tutorial.
I have tried looking for any information along these lines but it has been hard to find.
In principle, there's nothing about Windows Identity Foundation that makes it inappropriate for use on a "public-facing" website and WIF isn't in-itself tied to a particular authentication mechanism either. However, if you were considering using Active Directory Federated Services as your Identity Provider the problem would be that authenticating users against AD would be your only option since that's all it supports (although you can plug in a custom attribute store that retrieves claim values from some other datastore). Your WIF relying-party (i.e. your website) doesn't necessarily care how the user was authenticated, though, only that they were authenticated by an IDP that it trusts.
So your problem might not be that of "WIF-enabling" the websites as such, it may be more a question of finding a compatible IDP that supports authenticating against something other than Active Directory so that you can use the data store you currently use to authenticate users. It is possible to use ADFS as a "bridge" (a Relying-Party Security Token Server) between your WIF relying party and a SAML2 IDP like Shibboleth which can use a database to authenticate users, but configuring such a system is a significant challenge so you'd have to weigh up the benefits that your users might gain from single sign-on to your applications against the considerable effort it would take to set up and maintain such a system.
Yes - WIF appropriate for public facing web site authentication. ADFS v2.0 only authenticates against AD. However, you can write a custom STS that authenticates against anything you like. In your case, with a data store, have a look at Identity Server which authenticates against a SQL DB.
Have a look at:
http://claimsid.codeplex.com/
Identity Training Kit
How to: Build an ASP.NET STS
I'm having a discussion with out internal developers on using Active Directory Lightweight Directory Services instead of custom-rolling our own scheme to manage authentication and access to our application. They think it will be more complicated / time consuming to use AD LDS and also that AD LDS will be less configurable (flexible) than a custom solution.
I don't see why. I understand with AD LDS you can deploy your own schema.
Our app (C#, ASP.net) will need to authenticate via Web services and Web pages.
Does anyone have experience with this?
I've actually just finished a project to integrate the company's application to an Active Directory. It was pretty simple and painless.
You should go for AD. It's very simple to authenticate a user via C# code (at least from .NET 3.5 on). And you will gain the great advantage of having a single authentication repository for multiple applications.
Look here for a few examples: Everything in Active Directory via C#.NET 3.5 (Using System.DirectoryServices.AccountManagement)
As you can see, you can validate credential in 5 to 6 lines of code. Also, it is worth looking here, Microsoft's page on AD handling in .NET 3.5.