Keep on learning, keep on writing. Today I publish my notes regarding Security in .NET, especially the RBS System.

• Authentication identifies the user, Authorization checks for the rights of the user.
• To use existing Directory-Services you can use WindowsIdentity and WindowsPrincipal classes.
• For simple Database-driven security you can use and extend GenericIdentity and GenericPrincipal.
• For more control, you need to implement IIdentity and IPrincipal interfaces.

WindowsIdentity Class

• Namespace is System.Security.Principal.WindowsIdentity
• represents a Windows user account.
• provides access to username, authentication-type and account token.
• Does not allow you to authenticate a user. authentication is done by windows directly.
• three important methods to create a WindowsIdentity:
  • GetAnonymous – Returns WindowsIdentity representing anonymous user
  • GetCurrent – Returns current user as WindowsIdentity.
  • Impersonate – Returns a WindowsImpersonationContext for a specific user on the system.
• The Properties:
  • AuthenticationType – String representing the method, usually “NTLM”
  • IsAnonymous – Self explaining
  • IsAuthenticated – Self explaining
  • IsGuest – Self explaining
  • IsSystem – Is User Part of the System such as system accounts
  • Name – domain and username with backslash (ex. “Domain\Username”). If local, Domain = Machine name.
  • Token – Integer assigned by computer

WindowsPrincipal Class

• Namespace is System.Security.Principal.WindowsPrincipal
• Needs instance of WindowsIdentity in constructor.
• You can cast System.Threading.Thread.CurrentPrincipal to WindowsPrincipal to get the current users principal.
• Determine if user is in a specific roll by using WindowsPrincipal.IsInRole method with a member of System.Security.Principal.WindowsBuildInRole.
• Build-in groups are different depending on the OS.
• IsInRoll has an overload taking the Roll as String (ex. “MyDomain\MyRoll”)
• You can use the System.Environment.MachineName for local users and groups (ex. MachineName + “\Administrators”)

PrincipalPermission Class

• Namespace is System.Security.Principal.Permissions.PrincipalPermission
• there is a related Class called PermissionAttribute (for declarative Security)
• Three Important Properties which can be used in any combination. Important to memorize for exam.
  • Authenticated (requires the user to be authenticated or not)
  • Name (Identities Username)
  • Role (Principals Role)
• User .Demand method to check if current principal matches the requirements
• Security-Demands can be set declarative. Following actions are required
  • System.AppDomain.CurrentDomain.SetPrincipalPolity in code, to specify policy for current thread. (ex. PrincipalPolicy.WindowsPrincipal)
  • try/catch to catch System.Security.SecurityException when calling a protected method.
  • A PrincipalPermissions Attribute
• Disadvantages
  • Only entire methods can be protected#
  • Windows may throw an exception on runtime if method was called by a windows event.
• Example for declaration: [PrincipalPermission(SecurityAction.Demand, Role = "@”BUILTIN\Administrators”)]
• To use Imperative Security Demands follow these steps:
  • System.AppDomain.CurrentDomain.SetPrincipalPolity in code, to specify policy for current thread. (ex. PrincipalPolicy.WindowsPrincipal)
  • try/catch to catch System.Security.SecurityException when demanding.
  • PrincipalPermission object with properties set to restrictions.
  • call .Demand method of this object, remember try/catch
• PrincipalPermission has three overload constructors:
  • (PermissionState) – For using System.Security.Permissions.PermissionState
  • (Name, Roll) – If you only want to specify one, set the other to NULL.
  • (Name, Roll, IsAuthenticated) – Specify NULL for any property you don’t need.
• Example throwing exception if user is not in local Admin group: PrincipalPermission pp = new PrincipalPermission(null, @”BUILTIN\Administrators”,true); pp Demand();

Custom Users and Roles

• One way – implement IIdentity and IPrincipal.
• On IIdentity you need to implement the following Properties:
  • AuthenticationType – Your type as string, need to be unique within the Authentication mechanisms you are using.
  • IsAuthenticated – Indicator of Authentication
  • Name – Unique Username, you need to set this one even if its automatically done (GUID for example)
• Also you need to implement a constructor taking all the objects properties.
• It may be easier to inherit from WindowsIdentity or GenericIdentity (for non-Windows-Buildin-use) instead of implementing the interface.
• Implement IPrincipal for the security context of the user
• You must implement a constructor which accepts an IIdentity-object and a String-Array containing the roles.
• You must implement the .Identity Property
• You must implement .IsInRole-method
• GenericPrincipal and GenericIdentity can be filled very easy from a user-database and used within the application
• you can take advantage of declarative and imperative techniques by doing the following:
  • Create IIdentity or GenericIdentity for current user
  • Create IPrincipal or GenericPrincipal based on custom Identity object
  • Set Thread.CurrentPrincipal to custom principal
  • Now you can use the declarative and imperative techniques

Authentication Expections in Streams

• If Sysem.Net.Security.NegotiateStream or System.Net.Security.SslStream fails (cannot authenticate on any side) .NET throws one of two exceptions:
  • AuthenticationException – Prompt user for different credentials and then retry authentication
  • InvalidCredentialException – Stream is invalid, user cannot retry authentication

Thats from me, have fun learning

Sascha