More
CALL To Literature
To Know
-
John Does
Authorization vs Authentication
CALL To Literature
—
Feb 2021
Applying Authentication informs us who is accessing an application (correct identity); and Authorization informs if someone has access to functionality or resources (determined specific action).
Any person can go to a public square, but they have to show some credentials to access a private enterprise building.
With an application, it is the same. A user has to be identified, usually by informing a username and password. In this way, the user can be tracked along with the application for process, update or query any information. In some companies, tracking is essential for auditing compliance.
A person may be invited for a meeting in a company, but it doesn't mean that it's allowed to enter in the accounting room.
It's how authorization works in applications. Not all the persons have access to all functionalities of an application. For example, a user can have access to his salary, but only the manager can see the salaries of the members of the team. In fact, users only should have the necessary access to do their job, and thus it's what is called Principle of Least Privilege. In the same way of authentication, having a tracking of what each operation each user executed it's very important when auditing is a requirement.
There are many rules for authentication such as password length and hashing algorithms and this shouldn't be in control of the applications. Custom code is hard to maintain updated against company policies, can have security bugs and probably there will be duplicated code along with company applications.
Companies have external entities like Identity Management and LDAP servers which are responsible for authentication, known as Single Sign-On. For example:
The applications authenticate the users against these entities using the standard protocols like SAML, oAuth or OpenID (these will be discussed in a future article).
The way users or applications authenticate themselves depend on requirements and the device they are using. These are the most common authentication techniques:
Besides this process, the other reason that people don't have a certificate it's because there is a cost associated with them when a CA emit it. Because of that, the most common usage is inside companies, where they are responsible to generate a digital certificate for employees or mainly for machines so that a server can trust another server through a Client-cert authentication.
As it was commented above, companies usually have entities responsible for keeping the user storage and control the identity access and management, usually referred to as Identity Provider (IDP).
So instead of the application authenticates the users using a custom mechanism, it delegates the authentication, usually trough a configuration, to an IDP. So, in the first time user enters in the application, it's redirected to the IDP, which presents a login page. After the IDP authenticates the user successfully, returns a valid token, such as SAML, and the user it's redirected back to the application, which keeps the user authenticated for a time.
Usually, authorization is checked against user responsibilities, but an application can allow or deny access based on other elements such as an hour of the day or geographic position.
In applications, an anonymous user won't have access to any enterprise resources, so authorization really takes place after the user is authenticated.
Focusing on enterprise applications, the user is authenticated against Identity Provider, and in this context, there are two approaches:
While in the first approach it is required some configurations on IDP side, in the second one the responsibility stays with the application side, where the user's groups and attributes are checked used to create a rule.
In the application side the better option it is to configure any authorization rule using the infrastructure supporting the application, like the application server or the platform. Usually, these configurations are declarative, which implies a clear configuration and easy maintenance. When it's not possible to configure authorization in a declarative way, the alternative it is to insert conditions in the code, what it resolves the problem, but implies in hard maintenance.
These are the most common authorization techniques:
Some advantages of SSO:
https://www.okta.com/identity-101/authentication-vs-authorization/
https://dis-blog.thalesgroup.com/security/2017/08/29/identity-provider-idp-need-one/
Article by Ronaldo Fernandes
Applying Authentication informs us who is accessing an application (correct identity); and Authorization informs if someone has access to functionality or resources (determined specific action).
Any person can go to a public square, but they have to show some credentials to access a private enterprise building.
With an application, it is the same. A user has to be identified, usually by informing a username and password. In this way, the user can be tracked along with the application for process, update or query any information. In some companies, tracking is essential for auditing compliance.
A person may be invited for a meeting in a company, but it doesn't mean that it's allowed to enter in the accounting room.
It's how authorization works in applications. Not all the persons have access to all functionalities of an application. For example, a user can have access to his salary, but only the manager can see the salaries of the members of the team. In fact, users only should have the necessary access to do their job, and thus it's what is called Principle of Least Privilege. In the same way of authentication, having a tracking of what each operation each user executed it's very important when auditing is a requirement.
There are many rules for authentication such as password length and hashing algorithms and this shouldn't be in control of the applications. Custom code is hard to maintain updated against company policies, can have security bugs and probably there will be duplicated code along with company applications.
Companies have external entities like Identity Management and LDAP servers which are responsible for authentication, known as Single Sign-On. For example:
The applications authenticate the users against these entities using the standard protocols like SAML, oAuth or OpenID (these will be discussed in a future article).
The way users or applications authenticate themselves depend on requirements and the device they are using. These are the most common authentication techniques:
Besides this process, the other reason that people don't have a certificate it's because there is a cost associated with them when a CA emit it. Because of that, the most common usage is inside companies, where they are responsible to generate a digital certificate for employees or mainly for machines so that a server can trust another server through a Client-cert authentication.
As it was commented above, companies usually have entities responsible for keeping the user storage and control the identity access and management, usually referred to as Identity Provider (IDP).
So instead of the application authenticates the users using a custom mechanism, it delegates the authentication, usually trough a configuration, to an IDP. So, in the first time user enters in the application, it's redirected to the IDP, which presents a login page. After the IDP authenticates the user successfully, returns a valid token, such as SAML, and the user it's redirected back to the application, which keeps the user authenticated for a time.
Usually, authorization is checked against user responsibilities, but an application can allow or deny access based on other elements such as an hour of the day or geographic position.
In applications, an anonymous user won't have access to any enterprise resources, so authorization really takes place after the user is authenticated.
Focusing on enterprise applications, the user is authenticated against Identity Provider, and in this context, there are two approaches:
While in the first approach it is required some configurations on IDP side, in the second one the responsibility stays with the application side, where the user's groups and attributes are checked used to create a rule.
In the application side the better option it is to configure any authorization rule using the infrastructure supporting the application, like the application server or the platform. Usually, these configurations are declarative, which implies a clear configuration and easy maintenance. When it's not possible to configure authorization in a declarative way, the alternative it is to insert conditions in the code, what it resolves the problem, but implies in hard maintenance.
These are the most common authorization techniques:
Some advantages of SSO:
https://www.okta.com/identity-101/authentication-vs-authorization/
https://dis-blog.thalesgroup.com/security/2017/08/29/identity-provider-idp-need-one/
Article by Ronaldo Fernandes
Applying Authentication informs us who is accessing an application (correct identity); and Authorization informs if someone has access to functionality or resources (determined specific action).
Any person can go to a public square, but they have to show some credentials to access a private enterprise building.
With an application, it is the same. A user has to be identified, usually by informing a username and password. In this way, the user can be tracked along with the application for process, update or query any information. In some companies, tracking is essential for auditing compliance.
A person may be invited for a meeting in a company, but it doesn't mean that it's allowed to enter in the accounting room.
It's how authorization works in applications. Not all the persons have access to all functionalities of an application. For example, a user can have access to his salary, but only the manager can see the salaries of the members of the team. In fact, users only should have the necessary access to do their job, and thus it's what is called Principle of Least Privilege. In the same way of authentication, having a tracking of what each operation each user executed it's very important when auditing is a requirement.
There are many rules for authentication such as password length and hashing algorithms and this shouldn't be in control of the applications. Custom code is hard to maintain updated against company policies, can have security bugs and probably there will be duplicated code along with company applications.
Companies have external entities like Identity Management and LDAP servers which are responsible for authentication, known as Single Sign-On. For example:
The applications authenticate the users against these entities using the standard protocols like SAML, oAuth or OpenID (these will be discussed in a future article).
The way users or applications authenticate themselves depend on requirements and the device they are using. These are the most common authentication techniques:
Besides this process, the other reason that people don't have a certificate it's because there is a cost associated with them when a CA emit it. Because of that, the most common usage is inside companies, where they are responsible to generate a digital certificate for employees or mainly for machines so that a server can trust another server through a Client-cert authentication.
As it was commented above, companies usually have entities responsible for keeping the user storage and control the identity access and management, usually referred to as Identity Provider (IDP).
So instead of the application authenticates the users using a custom mechanism, it delegates the authentication, usually trough a configuration, to an IDP. So, in the first time user enters in the application, it's redirected to the IDP, which presents a login page. After the IDP authenticates the user successfully, returns a valid token, such as SAML, and the user it's redirected back to the application, which keeps the user authenticated for a time.
Usually, authorization is checked against user responsibilities, but an application can allow or deny access based on other elements such as an hour of the day or geographic position.
In applications, an anonymous user won't have access to any enterprise resources, so authorization really takes place after the user is authenticated.
Focusing on enterprise applications, the user is authenticated against Identity Provider, and in this context, there are two approaches:
While in the first approach it is required some configurations on IDP side, in the second one the responsibility stays with the application side, where the user's groups and attributes are checked used to create a rule.
In the application side the better option it is to configure any authorization rule using the infrastructure supporting the application, like the application server or the platform. Usually, these configurations are declarative, which implies a clear configuration and easy maintenance. When it's not possible to configure authorization in a declarative way, the alternative it is to insert conditions in the code, what it resolves the problem, but implies in hard maintenance.
These are the most common authorization techniques:
Some advantages of SSO:
https://www.okta.com/identity-101/authentication-vs-authorization/
https://dis-blog.thalesgroup.com/security/2017/08/29/identity-provider-idp-need-one/
Article by Ronaldo Fernandes
.png)
