lLIHENTICATION..~s.AIJ.

IHOJlIZATIQN_ _
\uth l"nhrnt 1on Aut horuuhon
Authe ntication is the process of verifying the identity of a Authorization is the process of allowing an authenticated
user by obtaining some sort of credentials and using those users to access the resources by checking whether the user
credentials to verify the user's identity. If the credentials has access rights to the system. Authorization helps you to
are valid, the au1horization process starts. Authentication control access rights by granting or denying specific
process always proceeds to Authorization process. For permissions to an authenticated user. In other words,
example, Alice logs in with her username and password, authorization is deciding whether a user is allowed to
and the server uses the password to authenticate Alice. perform an action. For example, Alice has permission to
get a resource but not create a resource.
3 Types: Windows Authentication, Fonns Authentication, 2 types: URL authorization and File a uthorization
and Passport Authentication
Authentication is implemented by writing following code Authorization is implemented by writing following code
in Web.Config file. in Web.Confie file.
<authorization>
<allow role!!- "Ad'Tlini!ltrator!! " />
<~y, t e::1 . ;;eb> <deny u!ler!l• tt~tt />
<authentication :node~ · [Window~ )form., IPa ~~port I None]" /> </authorization>
</~y~tem . web>
 LCOOKIEdJASED-AUillEN TICATIQ_._
N.._. _ __
Cookie-based authentication is stateful. This means that an authentication record or
session must be kept both server and client-side. The server needs to keep track of active
sessions in a database, while on the front-end a cookie is created that holds a session
identifier, thus the name cookie based authentication. Let's look at the flow of traditional
cookie-based authentication:
User enters their login credentials.
Server verifies the credentials are correct and creates a session which is then stored in a
database.
A cookie with the session ID is placed in the users browser.
On subsequent requests, the session ID is verified against the database and if valid the
request processed.
Once a user logs out of the app, the session is destroyed both client-side and server-side.

LCUOKIE-BASED--AIIIHEN ilCAilO~N_ _ ______,

• A cookie is basically just an item in a dictionary. Each item has a key and a value. For authentication, the
key could be something like 'usemame' and the value would be the username. Each time you make a
request to a website, your browser will include the cookies in the request, and the host server will check
the cookies. So authentication can be done automatically like that.
• To set a cookie, you just have to add it to the response the server sends back after requests. The browser
will then add the cookie upon receiving the response.
• There are different options you can configure for the cookie server side, like expiration times or
encryption. An encrypted cookie is often referred to as a signed cookie. Basically the server encrypts the
key and value in the dictionary item, so only the server can make use of the information. So then cookie
would be secure.
• A browser will save the cookies set by the server. In the HTfP header of every request the browser makes
to that server, it will add the cookies. It will only add cookies for the domains that set them. Example.com
can set a cookie and also add options in the HTfP header for the browsers to send the cookie back to
subdomains, like sub.example.com. It would be unacceptable for a browser to ever sends cookies to a
different domain.

CO~OKIEdlA.SED.-AU.IHEN TICATIQ_._..__ __
step by step description of how cookie based authentication works:
Step 1: Cllent > Signin g up

Before anything else, the user has to sign up. The client posts a HTTP request to the 5el'Ver
containing his/her username and password.

Step 2: server> Ha ndling sign up

The 5el'Ver receiV9s this request and hashes the password before storing the usemame and
password in your database. This way, if someone gains access to your database they won't see
your users' actual passwords.

Step 3 : Cllent > User logln

Now your user logs in. He/she provides their usemamelpassword and again, this is posted as a
HTTP request to the server.

Step 4: Server> Validating login

The 5el'Ver looks up the usemame in the database, hashes the supplied login password, and
compares lt to the previously hashed password in the database. If it doesn't dleck out, we may
deny them access by ~ a 401 stalus code and eodingJhe...mQ!JAS!.
LC01>KIEd3ASEn..AIITHENTICATin
~ N,_ _ __
step by step description of how cookie based authentication works:
Step 5: Server> Gener11ting 11ccess token

If ev8f}'thing checks out, we're going to aeate an access token, which uniquely identifies lhe user's
session. Still in the server. we do l'wo things with the access token:

1. Store it in !he database associated with that user

2. Attach ii to a response cookie to be retu rned to the client. Be sure to set an expiration
date/time to limit the user's session

Henceforth, the oookies wi!I be attached to every request (and response ) made between the c!ient
and server.

Step 6: Cllent > Making page requests

Back on the client sida, we are now logged in. Every time the dient makes a request for a page
that requires authorization (i.e. they need to be logged in), the server obtains the access token from
the cookie and checks it against the one in the database associated with that user. If it checks out,
access is granted.

This should get you started. Be sure to dear the cookies upon logout!

CndeAcc_es_s. Securi...__ _ _ _ _ _ _ _ _ __
Security is an essential part of an application and it should be taken into consideration from the grass-roots level of an
application's design. Security is all about protecting your assets from unauthorized actions.

-.qu-wtltbebrwarded
lolhe8u>in ..... conln>llu.

Clie nt1N1ke,;requ- lolhewebhostint1

::,",:;'.::::::.I , The .-.que,st contalnscredentlal 11· 10.A'sua:....,,. Respon oe
wlllbesentbacll; t othe
TheA!ioP. NET Core Module V2 (ntheHoorjn•
processwtllforward the.-.questtodotnec.e•
wherw thell.SP.N ETCo,eapplic.olioncodei•in•
procasshostad.
3. TheAuthentlcallonSe<vlcewlllconnecttothe
S..CurityStorw.TI>e...:uritysto,econtaln<tablff
forllser,llole,s,etc.
4. Thecredentlallnbrmallonwlllbeverifledand
the,e5l)Onoewlllbedell~e,edto authentic.ate

lcode Acc_e.ss Se.cur~i·~tv.:,..- - - - - - - - - - - - - - - 1

Every application that targets the common language runtime (that is, every managed application) must interact with
the runtime's security system. When a managed applica1ion is loaded, its host automatica lly grants it a set of
pennissions. These permissions arc determined by the host's local security settings or by the sandbox the application is
in. Depending on these pennissions, the application either runs properly or generates a security exception.

CAS enforces security policies in the .NET framework by preventing unauthorized access to protected resources and
operations. Unlike traditiona l security methods, where user credentials are obtained from the user, CAS is designed to
address the issues faced when obtaining code from external sources, which contain bugs and vu lnerabilit ies. These
bugs and vulnerabilities may make a user's system vulnerable to malicious code, which may be perfonning tasks
without the user knowing it. CAS actually knows and allows only those operations a given user's code can and cannot
perfonn. This feature is applicable to all managed code targeting the CLR.

Every application that targets the common language runtime (that is, every managed application) must interact with
the runtime's security system. When a managed application is loaded, its host automatica lly grants it a set of
permissions. These permissions are determined by the host's local security settings or by the sandbox the application is
in. Depending on these permissions, the application either runs properly or generates a security exception.

CAS provides evidence-based security built on a layer above the security provided by the Windows operating system.
While Windows is based on the pennissions of the user, CAS is based on the evidence for the assembly. The assembly
th ,. ·'-"- ;.., th ,. .,..,,1 th ,. f',,.r - 11 ,,,.

actions.
 lRole.Jlased Securicy_ _ _ _ _ _ _ _ _ _ _...,.
• Roles are often used in financial or business applications to enforce policy. For example, an application
might impose limits on the size of the transaction being processed depending on whether the user making
the request is a member of a specified role. Clerks might have authorization to process transactions that
are less than a specified threshold, supervisors might have a higher limit, and vice-presidents might have a
still higher limit (or no limit at all). Role-based security can also be used when an application requires
multiple approvals to complete an action. Such a case might be a purchasing system in which any
employee can generate a purchase request, but only a purchasing agent can convert that request into a
purchase order that can be sent to a supplier.

• .NET role-based security supports authorization by making infonnation about the principal, which is
constructed from an associated identity, available to the current thread. The identity (and the principal it
helps to define) can be either based on a Windows account or be a custom identity unrelated to a Windows
account. .NET applications can make authorization decisions based on the principal's identity or role
membership, or both. A role is a named set of principals that have the same privileges with respect to
security (such as a teller or a manager). A principal can be a member of one or more roles. Therefore,
applications can use role membership to determine whether a principal is authorized to perform a
requested action.

ole-hased Security,_ _ _ _ _ _ _ _ _ _ __
To provide ease of use and consistency with code access security, .NET role-based
security provides S},stem Security Permissions Principa!Permjssjon objects that enable
the common language runtime to perform authorization in a way that is similar to code
access security checks. The PrincipalPermission class represents the identity or role that
the principal must match and is compatible with both declarative and imperative security
checks. You can also access a principal's identity information directly and perform role
and identity checks in your code when needed .

.NET provides role-based security support that is flexible and extensible enough to meet
the needs of a wide spectrum of applications. You can choose to interoperate with
existing authentication infrastructures, such as COM+ 1.0 Services, or to create a custom
authentication system. Role-based security is particularly well-suited for use in
ASP.NET Web applications, which are processed primarily on the server. However,