Combine Domain, Exchange and forms authentication in MCV3 (Razor)
I'm working on a project that will be deployed to multiple 3d party servers - anything from Windows Server 2008, possibly to XP machines. It will need to incorporate several ways for users to authenticate - across intra and extra net. I'm now at a point that requires authentication implementation.
Can anyone recommend good articles or practices to achieve a combination of Exchange, Domain (Windows) and forms authentication (in that order) using MVC3?
(if enabled) Attempt exchange authentication => if failed or disabled, attempt windows authentication (again if enabled) => if all above fails, show forms authen开发者_C百科tication
All logins for different ways to authenticate will be stored in database (to link up with role and permission model).
Has anyone done this using dependency injected authentication provider? So you could inject and prioritize the providers when application starts.
You can combine LDAP (Domain and exchange use this) with forms authentication. Take a look at this article here:
http://support.microsoft.com/kb/316748
http://msdn.microsoft.com/en-us/library/ff649227.aspx
Thanks to Sac for reminding me about this old question. We do have a solution which caters to three authentication modes:
- Forms (default) List item
- Windows (pass-through)
- Mixed (Forms or LDAP)
The way to accomplish this is by having a standalone web site that performs authentication. The site can be swapped between Forms and Windows using web.config or IIS Manager. All other websites are configured to use Forms authentication and take a cookie produced by authentication site. The requirement for this to work is that all sites be on the same domain name (example domainname.com). All sites also need to share the same cookie name, domain name and validation key in web.config, example:
<authentication mode="Forms">
<forms name="CookieName" loginUrl="http://login.domainname.com/Authenticate" timeout="1200" slidingExpiration="true" domain="domainname.com"/>
</authentication>
<machineKey validationKey="123B3C89CB21F4F1422FF158A5B42D0E8DB8CB5CDA1742572A487D9401E3400267682B202B746511891C1BAF47F8D25C07C8C39D104696DB51F17C529AD3CABC" decryptionKey="8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72E" validation="SHA1"/>
When authentication site is set to windows, it also needs to know the domain against which it is authenticating - the domain name needs to be able to resolve against the domain controller. Our trick was to check the user who has authenticated through browser window prompt against internal list of allowed users and reject authentication if it doesn't match. You can do so by setting the context Credential back to null. This will redirect the user back to the login browser prompt. Regardless of Forms or Windows, an authentication cookie is always appended when user successfully authenticates.
When authentication site is set to Forms, it can use pure forms authentication by checking the username and password against internal list of users or the internal user can be assigned a domain name. In this case it performs authentication using LDAP protocol to contact the domain controller and authenticate with username and password they typed in. This facilitates mixed mode. Again there are examples out there on how to contact domain controller via LDAP.
The benefit of this setup is that only one of the sites (authentication) ever has to be swapped between Windows and Forms and the rest of the sites just piggy back on the cookie. Appending [Authorize] attribute to controller or actions on any site will look into in web.config and redirect to the loginUrl.
Feel free to comment if I forgot to mention something important.
精彩评论