LDAP is a standard communications protocol designed for “simple” queries against a directory database. A directory database is a specialized database that stores information about users, security, and network resources. There are many forms of LDAP servers from many vendors, both free and paid. See Active Directory for an example of Microsoft’s version of one.
Active Directory – What is it?
Active Directory is Microsoft’s version of an LDAP server. It’s a specialized type of database that stores information about users and network resources and security information about those users and resources.
Multiple AD servers on a large corporate network can be linked so that changes to one AD server get propagated to all of the other AD servers. This allows each geographical location to have its own copy of user accounts and network resource listings so that programs that need to query for them can query a local machine, rather than sending query requests out over the larger WAN, which is generally a very slow operation.
Intranet vs. Internet
Most everyone knows what the Internet is, but a lot of people are confused as to what an Inranet is. Simply put, it is a company’s own set of web sites that sit INSIDE the company’s firewall and are not available to users on the internet. It works just like the internet, only there’s nothing on it except for the company’s own servers, their own software, and their own web sites that are meant solely for internal employee use.
DMZ – DeMiliterized Zone
A DMZ is an area in a computer network that’s somewhat unprotected from security attacks because it is intentionally made available to computers outside of its internal, protected network.
Web servers (computers that host web sites on the internet) are generally the only computers in the DMZ. These computers are put in the DMZ primary for 2 reasons:
- To be accessible to the public at large.
- To be separated from the more protected computers on the company’s network.
One technical issue that comes up with this arrangement is that web servers almost always need to talk to computers inside the corporate firewall, such as database servers. To accommodate this, a “hole” is opened through the corporate firewall to allow very specific and narrow traffic to make its way between the web server and the database server(s).
Secure your Services Declaratively (PrincipalPermission)
Ever written a WCF Service and wondered what the best way to secure it was? Should you use SLL? (yes). What about authorization? Should you pass login names and passwords to each and every method? Should you create some kind of custom/proprietary token based system?
Or, is there a better, more standard, more secure way of doing it? Turns out, there is. All of the “solutions” listed above should be avoided (except, of course, for SLL encryption over the wire… You should do that).
The solution is with declarative security. In other words, you don’t have to code anything. You just sprinkle your class and/or your methods in your WCF service with attributes and .NET will take care of everything else for you.
Here’s how:
Suppose you have the following WCF service:
Code Snippet
- namespace MyCompany.MyLib.Services.Implementation.UserStuff
- {
- [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
- [ServiceBehavior(IncludeExceptionDetailInFaults=true)]
- public class MyLibServiceType : MyCompany.MyLib.Services.Interfaces.UserStuff.IMyLibServiceType
- {
- public bool DoesAccountExist(string DomainName, string LogInName)
- {
- return CustomUserType.DoesAccountExist(DomainName, LogInName);
- }
- }
- }
It’s a simple WCF Service that has one method “DoesAccountExist”, which takes two parameters for a user’s domain name and a login name. As-is, this service is unsecured. Anyone on the network can call it, and if this is in the DMZ, then anyone in the world can call it. hackers would love this. They can query for common domain names and login names and should be able to correctly guess a few. Plus, you don’t want unnecessary calls going into it anyway.
You need to secure this. This solution assumes this WCF service is on your company’s intranet, and is not exposed on the public internet (there’s a different solution for that).
Add the “PrincipalPermission” attribute to your DoesAccountExist method, like this:
Code Snippet
- [PrincipalPermission(SecurityAction.Demand, Role=“UserStuff_Callers”)]
- public bool DoesAccountExist(string DomainName, string LogInName)
- {
- return CustomUserType.DoesAccountExist(DomainName, LogInName);
- }
The PrincipalPermission attribute specifies that the credentials of the caller should be examined before allowing this method to be executed. The Role specifies an Active Directory group that the caller must belong to. If the caller’s credentials are NOT in the specified Active Directory group (“UserStuff_Callers” in this example), then the method won’t even run. Instead, a security exception will be thrown with “Access Denied” in the message.
Alternatively, you can apply the PrincipalPermission attribute at the class level, instead of at a method level. This way, not even an instance of the class can be made unless the security specified passes.
This capability is build all the way down into .NET’s CLR.
This is not a WCF feature. It’s a .NET feature. You can use this on ANY of your classes, properties, or methods.