We Keep Coding

Reading AuthorizationSection from web.config provides incorrect values

Edit #2: config.FilePath is showing that it's looking at a different file than what I'm expecting: "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config". I was expecting it to use the web.config in my project. Need to figure out why that's happening.
I have a method in my web API where I'm trying to read the values from the authorization section in my web.config. Based on what I've found, this should work:
public AuthorizationSetting GetAuthorizationSettings()
{
var config = WebConfigurationManager.OpenWebConfiguration(null);
var section = config.GetSection("system.web/authorization") as AuthorizationSection;
foreach (AuthorizationRule rule in section.Rules)
{
if (rule.Action.ToString().ToLower() == "allow")
{
Debug.WriteLine(rule);
}
}
return new AuthorizationSetting();
}
And this is the section of the web.config that contains the authorization info:
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5" />
<identity impersonate="true" />
<authentication mode="Windows" />
<authorization>
<allow roles="role1,role2,role3"/>
<deny users="*"/>
</authorization>
</system.web>
You can see that there is one allow and one deny. When I run the code, it appears that there is only one rule. Shouldn't there be two since there is an allow and a deny? And the one rule looks to have an Action of Allow and "*" for Users. That's not what's in the web.config. What am I missing here?
** Edit **
I've considered the possibility that it's reading a different web.config file. But there is only one other web.config file in the solution (under Views). I also changed it to have the same authorization section, but I still get the same result.

As you already figured out using Null in for the path parameter of OpenWebConfiguration loads the server root web.config in
%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Config\
the documentation says:
The virtual path to the configuration file. If null, the root Web.config file is opened.
but one could assume it would be the root web config of the site, not the server. Anyway, try using:
var config = WebConfigurationManager.OpenWebConfiguration("~");

Why can't I open a custom web.config file in my web ASP app?

I can't open a web.config file in my ASP web project.
I can add config files in my project for set the authorization pages.
I need to open these pages to be able to update the "Roles" names from my admin page.
After following the sample from Microsoft, it should be working normally:
http://msdn.microsoft.com/en-us/library/vstudio/4c2kcht0(v=vs.100).aspx
Here is the C# code I use :
//Open the web.config custom
Configuration config = WebConfigurationManager.OpenWebConfiguration("~/WebAuthorizationPilotageGeneral") as Configuration;
//Get the authorization section
// section is always == NULL !!!!
-> section = (System.Web.Configuration.AuthorizationSection)config.GetSection("authorization");
//Remove all Roles before add news Roles
section.Rules.Clear();
autho = new System.Web.Configuration.AuthorizationRule(System.Web.Configuration.AuthorizationRuleAction.Allow);
foreach (string role in Roles.GetAllRoles())
{
if (role != ttbx_RoleName.Text)
{
autho.Roles.Add(role);
}
}
//Add the news Roles
section.Rules.Add(autho);
//Save the web.config custom
config.Save(ConfigurationSaveMode.Full, true);
My web.config custom file I try to load to update "authorization" section
<!-- WebAuthorizationPilotageGeneral.config - access pilotage page -->
<authorization>
<allow roles="Administrator" />
<allow roles="Audit" />
<allow roles="Copil" />
<allow roles="System" />
<allow roles="User" />
<allow roles="visitor" />
<deny users="*" />
</authorization>
The weird things is after load the config file, my config object still have 22 sections, and should have only one => "authorization" , it's look like my (web.config) root file and not the (WebAuthorizationPilotageGeneral) config file.
UPDATE : I try to put my 4 config files on only one folder
Web.config file

In the MS examples, there is used relative config path without "~" symbol. Have you tried to remove it?
// Set the root path of the Web application that contains the
// Web.config file that you want to access.
string configPath = "/MyAppRoot";
// Get the configuration object to access the related Web.config file.
Configuration config = WebConfigurationManager.OpenWebConfiguration(configPath);

Validating a user on every page using session information, c# & ASP.NET

My question is more of a request for advice on how to implement a feature to a website using session information. I have a website that asks for username and password on the landing page. When a user successfully logs in, a session is created that stores their username and a few other variables related to the account. In the Page_Load function immediately following login, I successfully access this information attached to the user via session variables, verifying that it is implemented properly.
In the MySession class:
private MySession()
{
Username = Data.User.lblUsername;
CompanyId = Data.User.lblCompanyId;
}
In my welcome page (immediately following successful login)
private void Page_Load(object sender, System.EventArgs e)
{
secure_username = MySession.Current.Username;
...
}
I want to use this information, i.e. secure_username to validate the user once a page is accessed so that people can no longer skip the login form. From MySession class, do I simply use if(MySession.Current.Username == ??) statements to check each variable at the start of the Page_Load function, or is there a proper way to go about this?
Please ask for clarification if it is needed. Thanks.
EDIT: Based on some of the responses given, i think it is important to note that if a user suddenly becomes anonymous (or times out) they should be redirected to the login page.

If you are using form authentication then you can add following tags to web.config to deny any anonymous access. If you do this, you don't have to check if user is logged in on every page.
<authorization>
<deny users="?" />
</authorization>
Add this to allow all users to see Login.aspx so that they can login
<location path="Login.aspx" allowOverride="false">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
Add this so that all your css/images folders are visible to anonymous users
<location path="css" allowOverride="false">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
<location path="images" allowOverride="false">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
You may have to add extra location tags based on your website setup and the folders you want any anonymous user to have access to
If login form authentication session expires user will be redirected to url you mention in this tag
<forms loginUrl="Login.aspx" timeout="30">
</forms>

If you need to do the same action on every page it sounds like you need a base class where all your secure pages inherit from:
Base page:
public class BasePage : System.Web.UI.Page
{
public user secure_username
{get;set;}
protected void Page_Load(object sender, EventArgs e)
{
//add your checks that repeat on each page
}
}
Other pages:
public class AuthenticatedUsersPage : BasePage
{
}
Note: This of course assumes that you have already taken care of authorization and authentication on your config file (see rs' answer for more info). Also, if you are using forms authentication, remember to make your session last longer than your forms authentication timeout.

Roles authentication is not working in asp.net

I am using the code below to access a page base based upon user authentication
if (user.FirstOrDefault() == HashedPassword)
{
string roles = "Member";
// Create the authentication ticket
FormsAuthenticationTicket authTicket = new
FormsAuthenticationTicket(1, // version
loginName.Text, // user name
DateTime.Now, // creation
DateTime.Now.AddMinutes(60),// Expiration
false, // Persistent
roles); // User data
// Now encrypt the ticket.
string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
// Create a cookie and add the encrypted ticket to the
// cookie as data.
HttpCookie authCookie =
new HttpCookie(FormsAuthentication.FormsCookieName,
encryptedTicket);
// Add the cookie to the outgoing cookies collection.
Response.Cookies.Add(authCookie);
Response.Redirect("/Members/ClientAccount.aspx");
}
else
{
Response.Redirect("signin.aspx");
}
}
The user is getting directed to ClientAccount.aspx if the login details are correct but I want that to happen only if his/her role is set as Admin as shown in the web.config file below .
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="members.aspx">
<system.web>
<authorization>
<allow roles="Member" />
<allow roles="Admin" />
<deny users="?" />
</authorization>
</system.web>
</location>
<location path="ClientAccount.aspx">
<system.web>
<authorization>
<allow roles="Admin" />
<deny roles="Member"/>
<deny users="?" />
</authorization>
</system.web>
</location>
</configuration>
How do I make this happen ?
I guess the web.config file is not looking at the cookie to do the authorization so I am doing something wrong there.

Double check your location path relative to the web.config, my guess is that is the problem.
<location path="/Members/ClientAccount.aspx">
...
</location>
Of course you'll need to do something else instead of this line, you were just doing this for testing I'd assume?
Response.Redirect("/Members/ClientAccount.aspx");
i.e. redirect them to a page you know they're not allowed to hit. I figure you're going to beef that part up once you're sure its not allowing members to access that page.
You should make sure your web.config has the following tag:
<authentication mode="Forms" />
You need to configure it right, there are lots of options:
<authentication mode="Forms">
<forms loginUrl="Login.aspx"
protection="All"
timeout="30"
name=".ASPXAUTH"
path="/"
requireSSL="false"
slidingExpiration="true"
defaultUrl="default.aspx"
cookieless="UseDeviceProfile"
enableCrossAppRedirects="false" />
</authentication>
http://msdn.microsoft.com/en-us/library/ff647070.aspx

hey there, did you mean to have
<deny roles="Member"/>
right now, the deny policy really doesn't need the member role listed. If you are wanting member to also be allowed to that page, you will need to swap out the deny, to allow:
<authorization>
<allow roles="Admin" />
<allow roles="Member"/>
<deny users="?" />
</authorization>

Context.User losing Roles after being assigned in Global.asax.Application_AuthenticateRequest

I am using Forms authentication in my asp.net (3.5) application. I am also using roles to define what user can access which subdirectories of the app. Thus, the pertinent sections of my web.config file look like this:
<system.web>
<authentication mode="Forms">
<forms loginUrl="Default.aspx" path="/" protection="All" timeout="360" name="MyAppName" cookieless="UseCookies" />
</authentication>
<authorization >
<allow users="*"/>
</authorization>
</system.web>
<location path="Admin">
<system.web>
<authorization>
<allow roles="Admin"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
Based on what I have read, this should ensure that the only users able to access the Admin directory will be users who have been Authenticated and assigned the Admin role.
User authentication, saving the authentication ticket, and other related issues all work fine. If I remove the tags from the web.config file, everything works fine. The problem comes when I try to enforce that only users with the Admin role should be able to access the Admin directory.
Based on this MS KB article along with other webpages giving the same information, I have added the following code to my Global.asax file:
protected void Application_AuthenticateRequest(Object sender, EventArgs e) {
if (HttpContext.Current.User != null) {
if (Request.IsAuthenticated == true) {
// Debug#1
FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(Context.Request.Cookies[FormsAuthentication.FormsCookieName].Value);
// In this case, ticket.UserData = "Admin"
string[] roles = new string[1] { ticket.UserData };
FormsIdentity id = new FormsIdentity(ticket);
Context.User = new System.Security.Principal.GenericPrincipal(id, roles);
// Debug#2
}
}
}
However, when I try to log in, I am unable to access the Admin folder (get redirected to login page).
Trying to debug the issue, if I step through a request, if I execute Context.User.IsInRole("Admin") at the line marked Debug#1 above, it returns a false. If I execute the same statement at line Debug#2, it equals true. So at least as far as Global.asax is concerned, the Role is being assigned properly.
After Global.asax, execution jumps right to the Login page (since the lack of role causes the page load in the admin folder to be rejected). However, when I execute the same statement on the first line of Page_Load of the login, it returns false. So somewhere after Application_AuthenticateRequest in Global.asax and the initial load of the WebForm in the restricted directory, the role information is being lost, causing authentication to fail (note: in Page_Load, the proper Authentication ticket is still assigned to Context.User.Id - only the role is being lost).
What am I doing wrong, and how can I get it to work properly?
Update: I entered the solution below

Here was the problem and solution:
Earlier in development I had gone to the Website menu and clicked on Asp.net configuration. This resulted in the following line being added to the web.config:
<system.web>
<roleManager enabled="true" />
</system.web>
From that point on, the app was assuming that I was doing roles through the Asp.net site manager, and not through FormsAuthentication roles. Thus the repeated failures, despite the fact that the actual authentication and roles logic was set up correctly.
After this line was removed from web.config everything worked perfectly.

this is just a random shot, but are you getting blocked because of the order of authorization for Admin? Maybe you should try switching your deny all and your all Admin.
Just in case it's getting overwritten by the deny.
(I had code samples in here but they weren't showing up.