Fortinet white logo
Fortinet white logo

WAF Solutions against OWASP Top 10 Risks

7.6.3

Rendering resources based on user roles

Rendering resources based on user roles

A company has an internal web application used for managing sensitive customer data, including personal information and financial records. The application uses Role-Based Access Control (RBAC) to restrict access to different sections of the application based on user roles. There are three primary roles defined:

  • Admin: Full access to all data and application functionality.

  • Manager: Access to customer data but restricted from accessing financial records.

  • Employee: Limited access to basic customer information, without any access to sensitive personal information or financial records.

Solutions by FortiWeb

Securing Role-Based Access Control (RBAC) for back-end servers ensure that only authorized users can access specific back-end resources.

It's recommended to configure settings on your back-end servers to define user roles based on job functions and responsibilities within the organization. Despite that FortiWeb doesn't directly manage user roles, it still plays a crucial role in the broader security framework to help enforce RBAC security.

FortiWeb provides the following features for user authentication and access control:

User authentication with FortiWeb via remote authentication servers

Applications often use an authentication server to validate user credentials and verify their identity. It acts as a gatekeeper, ensuring that only authorized users can access specific resources or services.

FortiWeb supports integration with the most common authentication servers. It allows you to use FortiWeb to authenticate HTTP/HTTPS clients before they are permitted to access a web page. Authentication can use remotely-defined accounts whose credentials are confirmed with the following authentication servers:

  • LDAP queries
  • RADIUS queries
  • NTLM queries
  • KDC queries
  • SAML queries
  • TACACS+ queries

For more information, see Offloading HTTP authentication and authorization.

Single sign-on for multiple web applications

You can configure single sign-on (SSO) and combination access control and authentication on FortiWeb if your users will be accessing multiple web applications on your domain. For example, users can use the same Google account to access multiple Google applications such as Gmail, Chrome, etc.

This requires the user accounts to be defined on an LDAP server (such as Microsoft Active Directory) or a RADIUS server.

For more information on SSO, see:

Retrieving user attribute from the authentication server

FortiWeb supports retrieving user attributes from the LDAP server and forwarding them to the back-end server. It is useful in scenarios where the back-end server needs detailed user information to achieve granular user management, such as rendering resources based on the user's role.

For example, if you want FortiWeb to extract the value of the Email attribute and forward it as an HTTP header in the packet to the back-end server, configure the following settings.

In LDAP server (User > Remote Server > LDAP Server), add the following attribute so that FortiWeb can retrieve the value of the user's Email attribute from the LDAP server.

Name

ATTRIBUTE1

Attribute Name Email

In Site Publish rule (Application Delivery > Site Publish > Site Publish), add the following custom header so that FortiWeb can forward the value of the user's Email attribute to the back-end server:

Custom Header Name

LDAP-Email

Custom Header Value Format $LDAP.ATTRIBUTE1

When FortiWeb receives a request from a client, it will retrieve the "Email" attribute of this user from the LDAP server (assuming it is "Email:user1@example.com"), then forward the following HTTP header to the back-end server:

LDAP-Email:user1@example.com.

The back-end server then renders resources based on user's role which is indicated by the information of the user attribute.

For more information, see Retrieving LDAP users attributes (7.6.0).

The above features apply to scenarios where you have defined Role-Based Access Control (RBAC) on your back-end server. If you haven't defined RBAC but still want to control the access to certain resources, refer to the alternative methods in Preventing unauthorized users accessing admin path. However, be aware that defining RBAC on your back-end server should always be a high-priority solution.

Rendering resources based on user roles

Rendering resources based on user roles

A company has an internal web application used for managing sensitive customer data, including personal information and financial records. The application uses Role-Based Access Control (RBAC) to restrict access to different sections of the application based on user roles. There are three primary roles defined:

  • Admin: Full access to all data and application functionality.

  • Manager: Access to customer data but restricted from accessing financial records.

  • Employee: Limited access to basic customer information, without any access to sensitive personal information or financial records.

Solutions by FortiWeb

Securing Role-Based Access Control (RBAC) for back-end servers ensure that only authorized users can access specific back-end resources.

It's recommended to configure settings on your back-end servers to define user roles based on job functions and responsibilities within the organization. Despite that FortiWeb doesn't directly manage user roles, it still plays a crucial role in the broader security framework to help enforce RBAC security.

FortiWeb provides the following features for user authentication and access control:

User authentication with FortiWeb via remote authentication servers

Applications often use an authentication server to validate user credentials and verify their identity. It acts as a gatekeeper, ensuring that only authorized users can access specific resources or services.

FortiWeb supports integration with the most common authentication servers. It allows you to use FortiWeb to authenticate HTTP/HTTPS clients before they are permitted to access a web page. Authentication can use remotely-defined accounts whose credentials are confirmed with the following authentication servers:

  • LDAP queries
  • RADIUS queries
  • NTLM queries
  • KDC queries
  • SAML queries
  • TACACS+ queries

For more information, see Offloading HTTP authentication and authorization.

Single sign-on for multiple web applications

You can configure single sign-on (SSO) and combination access control and authentication on FortiWeb if your users will be accessing multiple web applications on your domain. For example, users can use the same Google account to access multiple Google applications such as Gmail, Chrome, etc.

This requires the user accounts to be defined on an LDAP server (such as Microsoft Active Directory) or a RADIUS server.

For more information on SSO, see:

Retrieving user attribute from the authentication server

FortiWeb supports retrieving user attributes from the LDAP server and forwarding them to the back-end server. It is useful in scenarios where the back-end server needs detailed user information to achieve granular user management, such as rendering resources based on the user's role.

For example, if you want FortiWeb to extract the value of the Email attribute and forward it as an HTTP header in the packet to the back-end server, configure the following settings.

In LDAP server (User > Remote Server > LDAP Server), add the following attribute so that FortiWeb can retrieve the value of the user's Email attribute from the LDAP server.

Name

ATTRIBUTE1

Attribute Name Email

In Site Publish rule (Application Delivery > Site Publish > Site Publish), add the following custom header so that FortiWeb can forward the value of the user's Email attribute to the back-end server:

Custom Header Name

LDAP-Email

Custom Header Value Format $LDAP.ATTRIBUTE1

When FortiWeb receives a request from a client, it will retrieve the "Email" attribute of this user from the LDAP server (assuming it is "Email:user1@example.com"), then forward the following HTTP header to the back-end server:

LDAP-Email:user1@example.com.

The back-end server then renders resources based on user's role which is indicated by the information of the user attribute.

For more information, see Retrieving LDAP users attributes (7.6.0).

The above features apply to scenarios where you have defined Role-Based Access Control (RBAC) on your back-end server. If you haven't defined RBAC but still want to control the access to certain resources, refer to the alternative methods in Preventing unauthorized users accessing admin path. However, be aware that defining RBAC on your back-end server should always be a high-priority solution.