User-Based Security

for RuBoard

User -Based Security

From the perspective of traditional user-based security, the authentication question is: Who is the identity attempting to do the action? An identity is typically a user or account name . Credentials are what you present to prove who you are; they are evidence presented for verification. A credential might be your password, a smart card, or a biometric device. The user's credentials must be verified with some security authority. An example of this is verifying a user's password against their login name based on a database of user names and encrypted passwords. Systems that allow unverified access are said to allow anonymous access. In security lingo the identity that can be authenticated is referred to as the principal .

The authorization question is: Can the identity perform the action they want? The principal is then compared to some list of rights to determine whether access is allowed. For example, when you access a file, your user name is compared with an Access Control List for the action you want to do in order to determine whether you can access the file. Of course, access is not always all or nothing. You might have read, but not modify rights to a file.

In a multitier architecture, the identity under which the server executes is often very powerful, and you want to restrict the ability of the client that makes a request to some subset of privileges the server has. In other cases, such as anonymous access, the server may not know who the client really is. The server then impersonates the client. Code executes under the identity of the client, instead of the server. In the case of anonymous access, the server runs under the identity of some preset user account.

Windows security under .NET, and ASP.NET security, are based on the concepts of user-based security.

for RuBoard