I am building a site using ASP.NET MVC 2. The site itself needs to be public but the admin section should require a windows login and the user logging in needs to have local admin privileges on the server.
i.e. http://server/site should be open, but http://server/site/admin should force an admin login before proceeding.
Can this be done in code or by tweaking the web.config file? If necessary, making configuration changes to IIS is acceptable but I am trying to keep deployment steps down to a minimum.
I don't know if you can do this in web.config, or even if it's possible via IIS in an MVC application (since /site/admin won't exist on the file system), but it is possible to have different permissions for different folders under IIS. You will need to use the IIS manager to configure this.
You may also be able to use an AuthorizeAttribute on your admin controller.
This turned out to be fairly straightforward:
Enable Windows Authentication in IIS.
Enable Windows Authentication in web.config.
Decorate each action that needs to be secure with [Authorize(Roles = "Admin")].
Related
I have installed several application on a BizTalk 2020 server using BTDF 5.8 where I used to the application settings in the deployment to update any config for the BizTalk applications.
My own account is part of the SSO admin group and I use the in proc host account to install the apps into the BizTalk server. The proc host account is also part of the SSO admin group.
When I view the SSO using the admin or client utility no apps are shown. I also downloaded and run the BizTalk-Server-SSO-Application-Configuration-Tool. The tool also showed no current installed applications, but was able to add an application with it config.
But ideally I would like to view and edit current config as I am currently getting an error on a server with incorrect value.
Is there another tool to view and edit settings or am I missing something that must be enabled.
My target site needs AD auth to browse and use the admin portal. All is fine there. This means syncing to this server via username and password authentication doesn't work. Does this mean i need to enable x.509 authentication?
If you mean using the Staging Module, the staging module's "Username and password" really is not linked to the actual CMS Users. You can put whatever Username and Password on the Destination server, and connect to it from the Source.
x.509 is also fine.
Tell me if you aren't talking about the Staging Module though.
You may need to do 1 of 2 things:
Enable mixed mode authentication. Yes the overall authentication doesn't need to use a physical cms_user user but since you have AD Authentication enabled, anytime another user or service tries to access a system page it may require them to log in.
Create a web.config location node in your /CMSPages/Staging/web.config file that excludes anyone or everyone to access a the SyncServer.asmx page within there.
Otherwise configure the x.509 certificate setup.
We currently have a FileMaker Server instanace running, it already has PHP web publishing running.
I'm just wondering is it as simple as ticking enable XML web publishing for it to be up and running or have I got to restart the server??
Thanks
You need to enable it in the server deployment, then you need at least 1 user account in the file with the extended privilege to grant access via php/xml/iwp etc. You will need a user account in EACH file you want to have access to with the appropriate extended privilege.
Then comes the fun of actually working with the FMXML or FMPHP engine hehe.
So I have an MVC 2 App running on Windows Azure.
Everything works fine, but I want to create a subdomain where I can test some stuff that I need the actual server for, but I don't want anyone to see it. However, if I just put up like www.mywebsite.com/sandbox - anyone COULD technically access it, even though they'd have to know it's there, which I don't want.
Is there anyway I can setup something like that and password protect it or something easily? If so, I would use the same sort of thing for a private administrative URL where team members only could go in and check stuff (with a username/password that I maintain).
As far as I see it, you have two options available.
Create a staging deployment, and make the IIS web site respond to a specific DNS request (e.g. http://sandbox.mywebsite.nothere). Either change your DNS settings, or chane your local hosts file (e.g. in C:\Windows\System32\drivers\etc\hosts). This is security through obscurity, and while it's not effective, it's easy and perhaps a good start.
As suggested by Steve Morgan in a comment, implement authentication in your application. If you have an ASP.NET (MVC or not) application (I'm assuming MVC in my example), you can do with something like this:
Create a MembershipController
Create a Login action accepting username and password, implementation looking like this:
public virtual ActionResult Login(Qinoa.Web.Models.LoginData model)
{
if(model.Username == "myuser" && model.Password == "hardcodedPassword") {
FormsAuthentication.SetAuthCookie("myuser", model.RememberMe);
}
return RedirectToAction(MVC.Home.Index());
}
In your web.config file, set
<authentication mode="Forms">
<forms loginUrl="~/Membership/Login" timeout="2880" />
</authentication>
On all your test containers add an [Authorize] attribute. Your app is now (rudimentary) protected.
On a side note to #1: you can host multiple sites on one web role.
Configure your application using Windows Identity Foundation and the Access Control Service.
You then have a choice of Identity Providers that you can use to secure your application without managing your own users.
Even better, if you have Active Directory is to deploy ADFS 2.0 internally. The beauty of that is that even if someone reaches your application, they can't authenticate if they don't also have access to network on which your ADFS server runs.
I'm securing an Azure application this way and it works very well. I get transparent integrated authentication but it's highly secure.
You don't need to expose AD or ADFS outside your network to do this; there's no communication between Azure and ADFS, it's all done via the browser.
I'm in the process of pulling a classic ASP app into Mvc2. I'll be deploying to an intranet and have been asked to enable support for Windows Authentication. The network I'll be deploying to has a few AD Domains and I'll only need to integrate with one in particular. Is it possible to use Windows Authentication and only allow authentication within a particular domain?
Along those same lines, it's not uncommon for a user to have an account in multiple domains (the account names themselves are typically different) - in the event a user logs in with an "unsupported" domain I'd like to kick them to a login form. Is this possible simply using Windows Auth or am I better off looking for an alternative?
Pro Tip:
Whatever you do don't implement Windows Authentication via IIS. Have a Forms Authentication page in your MVC app but use the LDAP authentication provider. This way you avoid the differences between how browsers implement Windows Authentication (only works well in IE and that's not a great reason).
The question "Is it possible to use Windows Authentication and only allow authentication within a particular domain?" has always has one and only one answer in my consulting experience: the answer is the permissions that you set for authenticated resources.
I've rarely found a deployment where there isn't some file, folder, server, COM+ object, SQL Role or database table that can't be "locked down" to only allow access by the subset of users you're targeting (e.g. "DOMAIN\Domain Users"):
Set permissions on the ASPX files (or the folder containing them, along with inheriting to the files) that are the "front door" (and optionally, all the others) so that they're only accessible to users in the "Domain Users" group for the allowed domain
restrict logon rights on the server that hosts the web site, so that only the Domain Users group have the appropriate rights - depending on the authentication provider used, this could be "allow logon locally" or "access this computer from the network"
set permissions at some layer of Component Services
restrict the SQL Server roles so that only "Domain Users" have the ability to read & execute the necessary database objects