We Keep Coding

Implement ADFS with asp.net roles

I have been working on a project where I have a simple web page integrated with AD FS. The authentication and website are working as expected. I am using VS 2015. My goal is to limit what users can access at the site, "roles" from what I have read and researched. If the logged on user is an admin, grant full access, but if logged on as a regular user limit what pages are available.
Here is the scenario, go to my project URL which is redirected to AD FS sign on, after successful sign on you are at my website. Not much to it.
I have read so much online about different ways to achieve my goal that I am unsure which course is best or simplest to configure. What are my best options here? Keep in mind I have never developed in asp or any other code for that matter. Any help would be appreciated.

There is policy based authorization that is probably the current best practice, however it sounds like role based authorization may be sufficient for you.
To perform role based authorization you'll first need to setup a claim rule in your ADFS for the Relying Party Trust of your application that sends the Role claim type "http://schemas.microsoft.com/ws/2008/06/identity/claims/role". The claim rule would look like this,
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = ";tokenGroups;{0}", param = c.Value);
Then when your roles arrive at your application in these claims, you'll process them with Windows Identity Foundation (WIF), which is integrated into .NET Framework 4.5+. I believe referencing System.Security.Claims is sufficient to get WIF in your project for processing roles. This "processing" however is done for you by WIF.
At this point you should be able to simply decorate controllers and methods like the following to perform role based authorization, with these Roles equating to the names of groups you are a member of in Active Directory.
[Authorize(Roles = "Administrators")]
public class AdminController : Controller
{
}

Just for interest, there are other ways to do this.
Once you have the roles, you can use IsInRole(role).
You can also use the web.config e.g.
<location path="Page.aspx">
<system.web>
<authorization>
<allow roles="Admin, OtherAdmin" />
<deny users="*" />
</authorization>
</system.web>

How to get current user who's accessing an ASP.NET application?

To get the current logged in user at the system I use this code:
string opl = System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString();
I work on an ASP.NET application where I need this information. So I've put my application on a server and tried the code above, and I get "Network Service" in the string opl. I need to know the current user of the PC who accesses my ASP.NET application.

The quick answer is User = System.Web.HttpContext.Current.User
Ensure your web.config has the following authentication element.
<configuration>
<system.web>
<authentication mode="Windows" />
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</configuration>
Further Reading: Recipe: Enabling Windows Authentication within an Intranet ASP.NET Web application

Using System.Web.HttpContext.Current.User.Identity.Name should work.
Please check the IIS Site settings on the server that is hosting your site by doing the following:
Go to IIS → Sites → Your Site → Authentication
Now check that Anonymous Access is Disabled & Windows Authentication is Enabled.
Now System.Web.HttpContext.Current.User.Identity.Name should return something like this:
domain\username

If you're using membership you can do: Membership.GetUser()
Your code is returning the Windows account which is assigned with ASP.NET.
Additional Info Edit:
You will want to include System.Web.Security
using System.Web.Security

The best practice is to check the Identity.IsAuthenticated Property first and then get the usr.UserName like this:
string userName = string.Empty;
if (System.Web.HttpContext.Current != null &&
System.Web.HttpContext.Current.User.Identity.IsAuthenticated)
{
System.Web.Security.MembershipUser usr = Membership.GetUser();
if (usr != null)
{
userName = usr.UserName;
}
}

You can simply use a property of the page. And the interesting thing is that you can access that property anywhere in your code.
Use this:
HttpContext.Current.User.Identity.Name

Don't look too far.
If you develop with ASP.NET MVC, you simply have the user as a property of the Controller class. So in case you get lost in some models looking for the current user, try to step back and to get the relevant information in the controller.
In the controller, just use:
using Microsoft.AspNet.Identity;
...
var userId = User.Identity.GetUserId();
...
with userId as a string.

The general consensus answer above seems to have have a compatibility issue with CORS support. In order to use the HttpContext.Current.User.Identity.Name attribute you must disable anonymous authentication in order to force Windows authentication to provide the authenticated user information. Unfortunately, I believe you must have anonymous authentication enabled in order to process the pre-flight OPTIONS request in a CORS scenario.
You can get around this by leaving anonymous authentication enabled and using the HttpContext.Current.Request.LogonUserIdentity attribute instead. This will return the authenticated user information (assuming you are in an intranet scenario) even with anonymous authentication enabled. The attribute returns a WindowsUser data structure and both are defined in the System.Web namespace
using System.Web;
WindowsIdentity user;
user = HttpContext.Current.Request.LogonUserIdentity;

I ran in the same issue.
This is what worked for me:
Setting up Properties of Windows Authentication in IIS
NTLM has to be the topmost.
Further Web.config modifications, make sure you already have or add if these do not exist:
<system.web>
<authentication mode="Windows" />
<identity impersonate="true"/>
</system.web>
<!-- you need the following lines of code to bypass errors, concerning type of Application Pool (integrated pipeline or classic) -->
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
See below a legit explanation for the two nodes and
Difference between <system.web> and <system.webServer>?
And, of course , you get the username by
//I am using the following to get the index of the separator "\\" and remove the Domain name from the string
int indexOfSlashChar = HttpContext.Current.User.Identity.Name.IndexOf("\\");
loggedInWindowsUserName = HttpContext.Current.User.Identity.Name.Substring(indexOfSlashChar + 1);

Query an AD domain via SSL

I have a domain and port number (636) as well as a username and password.
I am trying to figure out a way to connect to this AD via Secure LDAP and get a users 'givenname', 'sn', 'mail', and probably a few custom attributes.
However I have no idea how to do this in C#.
I think that Microsoft may have a method for this available already but I am going to defer to you all.
The final user experience will be: See login screen, enter username and password, those credentials are sent over LDAP and the users info is returned to my web app, then I log them in if it all went well... though I don't know what a failed attempt would look like either so I can deny them. Any ideas?
Please include code samples so I can understand the implementation, thanks!

Did you even try google?
EDIT
Sorry for the hubub and the snarky response. I think the problem you were having is you didn't quite ask the question right -- either here or on google. Anyhow, you don't need a lick of C# code here. You just need to configure your web app to use AD as a membership provider. You'll need a connection string [getting this right was the hardest part]:
<connectionStrings>
<add name="MyAd"
connectionString="LDAP://adserver/OU=Users"
/>
</connectionStrings>
And a membership provider:
<membership defaultProvider="AdProvider">
<providers>
<add
name="AdProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider,
System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="MyAd"
applicationName="ItRemoteHelpdesk"
enablePasswordReset="false"
/>
</providers>
</membership>
Then users can login with their normal username#domain and password.

The System.DirectoryServices.AccountManagement is the .NET dll to use for the newer, non-LDAP AD authentication.
Try this website for a good starting point with code examples:
http://www.codeproject.com/KB/system/usingAccountManagement.aspx

You should definitely check out the .NET 3.5 System.DirectoryServices.AccountManagement namespace as suggested by Brad.
To get a good head start on how to use it, read this MSDN Magazine article: Managing Directory Security Principals in the .NET Framework 3.5
The article does talk several times about how to securely (using SSL) connect to your AD domain, and how to e.g. create users or retrieve user information. I think reading that article closely and trying out the code samples should give you a good idea on how to do what you're looking for.
Update: quite obviously, all those method in S.DS.AM require you to be authenticated against AD. The new classes also provide for pretty simple verification of user credentials (as shown in that article I linked to):
// establish context
PrincipalContext domain = new PrincipalContext(ContextType.Domain);
// determine whether a user can validate to the directory
bool validated = domain.ValidateCredentials("user1", "Password1");

Best approach to store login credentials for website

I have created a site in ASP.NET 3.5 & I have only 2 or 3 user login IDs who can login to the website.
What would be the best way to save these login details? Which of these approaches, or others, would be most suitable?
Using Forms Authentication, and saving credentials (username and password) in web.config
to create a text file in directory and modify it
Which approach is best from a security and maintenance perspective? What other approaches are suitable for a login system for ASP.NET?

Use the default ASP.NET Sql Membership Provider. The link will show you how to used it and get it configured.

Do you already have a database? If so, use forms authentication and ASP.NET membership like everyone says. It is real simple to integrate into your current database (assuming it's sql server - i don't know about others). I realize adding a DB for 2 or 3 users isn't always an option due to budget or whatever so you can use forms authentication and store the user in the web.config. I've done this in the past and it is very simple.
Your web.config will look like:
<authentication mode="Forms">
<forms loginUrl="Login.aspx">
<credentials passwordFormat="Clear">
<user name="myUser" password="password" />
</credentials>
</forms>
</authentication>
Then you can use the built in login controls. If you do it this way you need to implement the Autenticate event.
protected void Login1_Authenticate(object sender, System.Web.UI.WebControls.AuthenticateEventArgs e)
{
string UserName = Login1.UserName;
string Password = Login1.Password;
if (FormsAuthentication.Authenticate(UserName, Password))
{
e.Authenticated = true;
}
else
{
e.Authenticated = false;
}
}
Of course this isn't the most secure way to go about this, and you'll probably want to at least look at encrypting the credentials in the web.config, but it is simple and works when a database isn't an option.

With ASP.NET you can use some of the built-in/provided authentication providers that let you manage the users in a database and it uses proper guidelines like hashing passwords, etc. by default.

You could use ASP.NET membership. Even though you won't have many users, it handles all of the authentication details for you.

How do you pass an authenticated session between app domains

Lets say that you have websites www.xyz.com and www.abc.com.
Lets say that a user goes to www.abc.com and they get authenticated through the normal ASP .NET membership provider.
Then, from that site, they get sent to (redirection, linked, whatever works) site www.xyz.com, and the intent of site www.abc.com was to pass that user to the other site as the status of isAuthenticated, so that the site www.xyz.com does not ask for the credentials of said user again.
What would be needed for this to work? I have some constraints on this though, the user databases are completely separate, it is not internal to an organization, in all regards, it is like passing from stackoverflow.com to google as authenticated, it is that separate in nature. A link to a relevant article will suffice.

Try using FormAuthentication by setting the web.config authentication section like so:
<authentication mode="Forms">
<forms name=".ASPXAUTH" requireSSL="true"
protection="All"
enableCrossAppRedirects="true" />
</authentication>
Generate a machine key. Example: Easiest way to generate MachineKey – Tips and tricks: ASP.NET, IIS ...
When posting to the other application the authentication ticket is passed as a hidden field. While reading the post from the first app, the second app will read the encrypted ticket and authenticate the user. Here's an example of the page that passes that posts the field:
.aspx:
<form id="form1" runat="server">
<div>
<p><asp:Button ID="btnTransfer" runat="server" Text="Go" PostBackUrl="http://otherapp/" /></p>
<input id="hdnStreetCred" runat="server" type="hidden" />
</div>
</form>
code-behind:
protected void Page_Load(object sender, EventArgs e)
{
FormsIdentity cIdentity = Page.User.Identity as FormsIdentity;
if (cIdentity != null)
{
this.hdnStreetCred.ID = FormsAuthentication.FormsCookieName;
this.hdnStreetCred.Value = FormsAuthentication.Encrypt(((FormsIdentity)User.Identity).Ticket);
}
}
Also see the cross app form authentication section in Chapter 5 of this book from Wrox. It recommends answers like the ones above in addition to providing a homebrew SSO solution.

If you are using the built in membership system you can do cross sub-domain authentication with forms auth by using some like this in each web.config.
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="~/Login.aspx" path="/"
protection="All"
domain="datasharp.co.uk"
enableCrossAppRedirects="true" />
</authentication>
Make sure that name, path, protection and domain are the same in all web.configs. If the sites are on different machines you will also need to ensure that the machineKey and validation and encryption keys are the same.

If you store user sessions in the database, you could simply check the existance of the Guid in the session table, if it exists, then the user already authenticated on the other domain. For this to work, you would have to included the session guid in the URL when you redirect the user over to the other website.

Not sure what you'd use for .NET but ordinarily I'd use memcached in a LAMP stack.

The resolution depends on the type of application and environment in which it is running. E.g. on intranet with NT Domain you can use NTLM to pass windows credentials directly to servers in intranet perimeter without any need to duplicate sessions.
The approach how to do this is generally named single sign-on (see Wikipedia).

There are multiple approaches to this problem, which is described as "Cross-domain Single Sign On". The wikipedia article pointed to by Matej is particularly helpful if you're looking for an open source solution - however - in a windows environment I belive you're best off with one of 2 approaches:
Buy a commercial SSO product (like SiteMinder or PingIdentity)
Use MicroSoft's cross-domain SSO solution, called ADFS - Active Direcctory Federation Services. (federation is the term for coordinating the behavior of multiple domains)
I have used SiteMinder and it works well, but it's expensive. If you're in an all MicroSoft environment I think ADFS is your best bet. Start with this ADFS whitepaper.

I would user something like CAS:
[1]: http://www.ja-sig.org/products/cas/ CAS
This is a solved problem and wouldn't recommend rolling your own.

Alternatively if you want to roll your own and the sites in question are not on the same servers or don't have access to a shared database (in which case see the above responses) then you could place a web beacon on each of the sites which would refer back to the other site.
Place a single pixel image (web beacon) on site A which would call site B passing through the users ID (encrypted & time stamped). This would then create a new user session on site B for the user which would be set as logged in. Then when the user visited site B they would already be logged in.
To minimise calls you could only place the web beacon on the home page and or log in confirmation pages. I've used this successfully in the past to pass information between partner sites.