Thursday, December 28, 2006
Identities and Principals
Identities
l An identity represents a certain user
l Identity is established through authentication by an authority
l Processes run code under an identity
l Access to some resources is granted based on a proven identity
Ø NTFS file system
Ø SQL Server and other server products working with Windows Integrated security
Ø Registry
l Usually identities are of type:
Ø Windows user
Ø ASP.NET Forms authenticated user
Ø Passport account
Ø Custom application account
Principals
l A principal represents an identity AND its roles
l Allows you to make security decisions
Ø Role Based Security (RBS):
§ Role membership is tested on a principal
§ Role is group of users with similar rights
Ø Identity
.NET Framework
l Dedicated namespace is System.Security.Principal
l .NET Framework provides two interfaces: IIdentity and IPrincipal
.NET Framework classes
l Use FCL classes or create custom implementation
l Custom implementations should implement IIdentity and IPrincipal
Acquiring a principal
l Principal objects can be acquired in two ways
Ø WindowsIdentity.GetCurrent() method, then create WindowsPrincipal
Ø Thread.CurrentPrincipal property
Ø ASP.NET only: HttpContext.Current.User
l Once acquired evaluate identities properties and/or check for role membership
Threads and threads
l CLR provides "soft" threads that map to real Win32 OS threads
l Principals on these need not be same
Role Based Security
l One of 2 security mechanisms in .NET
Ø Different from Code Access Security
l Checks on roles implemented through:
Ø Runtime evaluation of IPrincipal.IsInRole
Ø Compile-time attribute decoration with PrincipalPermissionAttribute
§ Used on class or individual methods
§ Automatically throws SecurityException if not authenticated or member of demanded role
Ø (ASP.NET) roles in or elements
l RBS uses Thread.CurrentPrincipal
Windows Identities and Principals
l Identity of Win32 thread leading for resource access
l Roles of Windows principal are Windows security groups
l Control how CLR assigns principal to CLR thread by setting AppDomain's PrincipalPolicy
Taking control of WindowsIdentity
l WindowsIdentity of Win32 thread determined by user token of process
l Different ways of setting
Ø Win32 executables:
§ Console
§ Windows Forms
§ Windows (NT) Services
Ø ASP.NET
Ø COM+ application (Enterprise Services)
Impersonation
l Setting a new identity onto executing Win32 thread, e.g. when:
Ø Identity of calling user has to be assumed
Ø Resource must be accessed through privileged account
l WindowsIdentity class has Impersonate method
Ø Takes a token of user to impersonate
Ø Returns a WindowsImpersonationContext
Ø Identity assumed until Undo is called
l Getting token not supported by managed code
Ø Some calls to Win32 API are necessary
Ø Mainly LogonUser
l Alternative offered by Enterprise Services (previously COM+)
l ASP.NET has built-in facilities for impersonation of calling user
Working with principals
l Create your own principals
Ø WindowsPrincipals are only created explicitly to evaluate Windows groups
Ø Generic principals for ASP.NET and custom authentication
l Set or replace principal of current thread
Ø By default new threads take principal from spawning thread
Ø Set principal for new threads using current AppDomain's SetThreadPrincipal method
Ø Code needs to have ControlPrincipal rights
Generic classes
l GenericIdentity and GenericPrincipal
Ø For custom authentication
Ø Used by ASP.NET Forms Authentication
l Complete freedom on choice of identity names and corresponding roles
Ø Probably based upon application specific scenario or requirements
Working with generic objects
l Common scenario
Ø Retrieve names and roles from database
Ø If credentials are stored in database, securely store password
l Create GenericIdentity first
Ø Constructor accepts string for username
l Principal is created by supplying:
Ø Previously created (Generic)Identity
Ø String array containing names of roles
Example Generic Principal
ASP.NET Forms Authentication
l By default Forms Authentication:
Ø uses generic identity and principal objects
Ø does not provide roles
l Create your own principal with roles
l Typically login page would contain principal creation code
l In disconnected, multithreaded world of ASP.NET a principal must be recreated and set on each request
Custom Forms Authentication
l Create principal on authentication moment AuthenticateRequest event in Global.asax
Ø Identity available from Forms Authentication session-ticket
l Retrieving roles for every request can be costly
Ø Store roles in encrypted cookie on login
Ø Retrieve roles from roles in AuthenticateRequest
COM+ identities and principals
l COM+ identity determined on Identity tab of application in Component Services tool
l COM+ role based security is different and separate from .NET's security
l Roles are defined in CS tool and Windows users are assigned to roles
l Test for role membership by using
Ø attribute on class, interface or method
Ø ContextUtil.IsCallerInRole as equivalent of IPrincipal.IsInRole
Security reminders
l Keep your passwords secret
Ø Even in your code or configuration files
Ø Use hashing or encryption
l Transmit password at least over a secure connection (e.g. HTTPS)
l Use a least privileged account for
Ø Accessing resources
Ø Identity of processes (such as ASPNET)
l Think of security up front
Summary
l Identity of application is important for accessing resources
l Principal allows for role based security
l Working with principals is different for Windows and ASP.NET applications
l Security is always important
Further reading
l .NET Magazine #5
Article on identities and principals covering this talk
Posted by
Nazish Ahsan
at
15:23:17
|
Permanent Link
|
|
