Network and Application Access Security: The Key to a Secure and Connected Enterprise

Network and Application Access Security: The Key to a Secure and Connected Enterprise

Technology has revolutionized the way we connect, work, and share information. In this context, Network and Application Access Security becomes a fundamental pillar to protect both users and companies, ensuring that access to resources is secure, efficient and in accordance with strict policies. This area of cybersecurity not only allows for proper access, but also protects us against access threats and vulnerabilities.

The importance of securing access to our networks and applications lies in the fact that these access points represent one of the main gateways to business data and resources. An unsecured access system is like an open door to cybercriminals, and as remote work and digitization continue their exponential growth, securing these “gateways” is more essential than ever.

In addition, ensuring access allows you to comply with regulations and security standards that are critical in sectors such as finance, health, and the public sector. Without adequate access policies and technologies, not only confidential information but also the trust of customers and users is put at risk.

Utility of Secure Access: Ensuring Efficiency and Protection

Having a robust system in place for access security means that authorized users can access the resources they need seamlessly, while threats are blocked. Secure Access means that companies can ensure a frictionless user experience through technologies such as SSO (Single Sign-On) or Multi-Factor Authentication (MFA), while IT and cybersecurity teams can monitor, control and respond to suspicious access.

In addition, access security simplifies identity and access management (IAM), reduces incident resolution time, and improves operational efficiency by reducing reliance on manual monitoring and authentication solutions.

Basics for Understanding Access Security: Building Security Blocks

  1. Federation: It is a system that allows interoperability between different domains and organizations to share identities securely. Allows users to use their credentials from one organization to access resources from another.
  2. IdP (Identity Provider): This is the identity provider, the entity that verifies and stores user identities. Services such as Azure AD, Google Identity, and Okta work as IdPs.
  3. SSO (Single Sign-On): Allows users to authenticate once to access multiple applications and services. It prevents password fatigue and reduces the security risk associated with using weak passwords.
  4. LDAP (Lightweight Directory Access Protocol): A protocol used to access and maintain distributed directory services. It is common in identity management.
  5. JWT (JSON Web Token): A secure token format used to transmit information between parties. It is ideal for mobile and web applications that require fast and secure authentication and authorization.
  6. SAML (Security Assertion Markup Language): XML-based protocol that facilitates the secure exchange of authentication and authorization between different entities. Ideal for enterprise SSO environments.
  7. OAuth: An authorization protocol that allows users to grant access to applications without sharing their credentials. It is common in mobile and cloud applications.
  8. OpenID is a technology that allows users to authenticate to various applications and websites using a single set of credentials. At its core, OpenID simplifies the user experience by allowing users to sign up and access multiple services using a unique identity managed by an OpenID Provider (OP), such as Google or Microsoft. Its main difference from OAuth is that OpenID is designed specifically for authentication, while OAuth focuses on authorization.

    With OpenID, a user authenticates with an identity provider that verifies their identity and then transfers that authentication to other services through an OpenID Connect token. OpenID is based on OpenID Connect (OIDC), an authentication layer that uses OAuth 2.0 for authorization, making it a secure and flexible technology for modern applications.

    OpenID is complemented by technologies such as OAuth and JWT to provide a complete authentication and authorization model. For example, in an OpenID Connect integration with OAuth 2.0, OpenID takes care of user authentication, while OAuth manages access permissions. This creates a secure and efficient workflow for web applications, where the user logs into an application using OpenID, and OAuth controls what the user can do within that application.
  1. Kerberos: Authentication protocol in networks, used primarily in enterprise environments that require mutually secure authentication between clients and servers.
  2. 802.1x: Standard protocol for port-based network access control, ensuring that only authorized users and devices can access the network.
  3. RADIUS (Remote Authentication Dial-In User Service): A protocol that centralizes authentication, authorization, and logging of access to a network. Used in conjunction with 802.1x for secure access.
  4. EAPExtensible Authentication Protocol (EAP) is an authentication protocol widely used in Wi-Fi networks and secure wired networks to facilitate different authentication methods (passwords, certificates, multi-factor authentication, etc.). EAP acts as a flexible framework that allows devices and servers to authenticate securely and is commonly used in conjunction with 802.1x and RADIUS.

    Common Types of EAPs:
    EAP-TLS (Transport Layer Security): Uses certificates to authenticate both the client and the server, being one of the most secure methods.
    EAP-TTLS (Tunneled TLS): Extends EAP-TLS by enabling username and password-based authentication within a secure tunnel.
    PEAP (Protected EAP): Create a secure channel using TLS and then authenticate with passwords or certificates.

Technologies and Their Functions in Access Security

TechnologyMain FunctionProtocol/StandardExample of Use
FederationCross-domain interoperabilitySAML, OAuthAccess between corporate applications from different companies
IdpIdentity verification and storageSAML, OAuthMicrosoft Azure AD, Okta
SSOSingle Sign-On for Multiple ApplicationsSAML, OAuthGSuite, Office 365
LDAPAccess to directory servicesLDAPActive Directory
JWTSecure data transmissionTokenAPI authentication
SAMLSecure authentication and authorization exchangeSAMLFederated SSO in Enterprise Environments
OAuthAuthorization without sharing credentialsOAuthAccess to apps with Facebook, Google
OpenIDAuthentication through a third-party providerOpenID ConnectLogin to websites using Google or Microsoft
KerberosNetwork Mutual AuthenticationKerberosCorporate environments with Active Directory
802.1xPort-based network access controlIEEE 802.1xSecure access on Wi-Fi networks
RADIUSNetwork Authentication and AuthorizationRADIUSImplementing VPN Access

Example of Deploying SSO with Microsoft Azure AD for Application Access

Microsoft Azure AD is an identity provider that enables organizations to efficiently deploy SSO. By configuring SAML or OAuth, users can authenticate once and gain access to all enterprise applications, such as Office 365, third-party applications, and on-premises systems. Azure AD integration simplifies management and ensures secure authentication for each user.

Suppose an employee in a company tries to access multiple applications through a single authentication using Azure AD (which acts as an IdP for SSO).

Step-by-Step Flow:

  1. App Login: The user tries to access an app, such as Office 365 or a custom app.
  2. Redirect to Azure AD: The application detects that the user is unauthenticated and redirects them to Microsoft Azure AD, the IdP configured for SSO.
  3. Credential prompt: Azure AD prompts for the user’s credentials (username and password or multi-factor authentication if configured).
  4. Credential verification: Azure AD validates the user’s credentials. If authentication is successful, it generates an authentication token (usually JWT).
  5. Token Delivery: Azure AD sends the authentication token to the initial application.
  6. In-App Token Validation: The application receives the token and verifies it to ensure that it is valid and issued by Azure AD.
  7. Multi-Application Access: Since the user is already authenticated to Azure AD, they can access other SSO-integrated applications without re-entering their credentials. This token has a limited lifetime, and when it expires, Azure AD transparently renews it.
  8. Full Access Permission: Finally, the user has access to all of the organization’s applications integrated into Azure AD, such as Office 365, SharePoint, and other systems.

Example of Federated SSO for Application Access

The federation allows different companies to work collaboratively without compromising the security of their access. Suppose a company wants to give access to its internal application to employees of a third-party vendor. By setting up a federation between your Azure AD and the provider’s IdP using SAML, external users are allowed to authenticate without creating new accounts on the company’s system.

Suppose a company called TechCorp collaborates with Global Solutions. TechCorp has internal applications (such as project management systems or CRM) that also need to be accessed by Global Solutions employees. Instead of creating accounts for each external user, TechCorp configures Federated SSO using Google as Global Solutions’ identity provider (IdP), employing the SAML protocol.

Step-by-Step Flow:

  1. External User Access Attempt:
     A Global Solutions employee  attempts to access a TechCorp application, such as their CRM. When the user tries to log in, TechCorp’s system identifies that the domain in their account belongs to Global Solutions.
  2. Redirect to Google IdP:
     TechCorp’s app redirects the user to Google’s login page, which is the IdP (identity provider) that handles Global Solutions authentications.
  3. Google Authentication Request:
     Google prompts the user for their account credentials (such as email and password) and validates them. This process may include multi-factor authentication (MFA) for added security.
  4. Generating a SAML Assertion:
     Once the user successfully authenticates to Google, Google generates a SAML Assertion. This is a digitally signed data package that includes authenticated user information, such as their identity, roles, and details needed for TechCorp to grant them access to their applications.
  5. Delivery of SAML Assertion to TechCorp:
     Google sends SAML Assertion to the TechCorp application. This is done securely and can only be read and validated by TechCorp.
  6. Assertion Validation in TechCorp: 
    TechCorp receives the SAML Assertion and verifies that it was indeed issued by Google (the Global Solutions IdP) and that it contains the necessary and reliable user data. This process confirms that the Assertion comes from an authoritative source.
  7. Application Access in TechCorp:
     Once the Assertion is validated, TechCorp grants the user access to the CRM application. From this point, the user can navigate and use the app with the appropriate permissions.
  8. Federated SSO Reuse: 
    Since the session is active and the Assertion has already been validated, the user can access other TechCorp applications that are configured for Federated SSO without needing to authenticate again for the duration of the session.

Example of Secure Network Access with 802.1x and RADIUS

For secure network access, many organizations configure 802.1x in conjunction with a RADIUS server. In this scenario, when a device attempts to connect to the network, 802.1x acts as an authenticator, sending the credentials to the RADIUS server. If the user is authorized, the device gains access to the network, and if not, access is denied. This allows for fine-grained and secure control of network access.

In this case, a device attempts to access a network protected by 802.1x and centralized authentication on a RADIUS server. Let’s say your device tries to connect to a secure Wi-Fi network.

Step-by-Step Flow:

  1. Attempted Wi-Fi Connection: The device (e.g., a laptop or smartphone) attempts to connect to the 802.1x-protected Wi-Fi network.
  2. Credential Request: The device sends its credentials to the 802.1x Authenticator (usually the Wi-Fi switch or access point) using the EAP (Extensible Authentication Protocol) protocol.
  3. Credential Redirection to RADIUS Server: The 802.1x authenticator passes credentials to  the RADIUS server, which is configured to handle authentication.
  4. Credential Validation by the RADIUS Server: The RADIUS server verifies credentials against a user database (such as Active Directory or LDAP) to confirm the identity of the device.
  5. Device Authorization: If the credentials are valid, the RADIUS server sends an acceptance message to the 802.1x authenticator, allowing the device to access the network.
  6. Connection Established: The authenticator allows the device to access the network and establishes a secure connection.
  7. Continuous Monitoring: Depending on the configuration, the RADIUS server can monitor the device’s session while it is connected and cut off access if it detects anomalous behavior.

Example of OpenID Implementation in Enterprise Environments

Let’s say an organization allows its employees to access various internal applications using centralized authentication in Azure AD using OpenID Connect. In this case, the employee can access productivity tools, CRM, and HR applications using their Azure AD credentials without needing to authenticate multiple times. In addition, by integrating OpenID Connect, you achieve greater efficiency in identity management and reduce exposure to risks related to credential theft.

Here, a company deploys OpenID Connect to enable its employees to access various internal and external applications using their Azure AD credentials.

Step-by-Step Flow:

  1. Third-Party Application Access: The user attempts to access a third-party application that is integrated with OpenID Connect.
  2. Redirect to OpenID Provider (OP): The application detects that the user is not authenticated and redirects them to their OpenID Provider, in this case, Azure AD.
  3. Authentication in Azure AD: Azure AD asks for the user’s credentials (user, password, or multi-factor authentication).
  4. Verification and Generation of an OpenID Token: If authentication is successful, Azure AD generates an ID Tokenin JWT format, which includes user information and access permissions.
  5. Delivery of the ID Token to the Application: Azure AD sends the OpenID token to the third-party application.
  6. Token validation: The application receives the token and validates it, verifying that it was issued by Azure AD and that the user has the necessary permissions.
  7. Application Access: The user gains access to the third-party application and can reuse this same token for other applications integrated with the same OpenID Provider until the token expires.

Example of Network Authentication Using EAP, 802.1x, and RADIUS

Suppose an employee tries to connect to an EAP-TLS-protected corporate Wi-Fi network, authenticated through a RADIUS server.

Step-by-Step Flow:

  1. Connection Attempt: The user’s device attempts to connect to the protected Wi-Fi network.
  2. 802.1x Authentication Request: The Wi-Fi access point (Authenticator) sends an 802.1x authentication challenge, asking the device to initiate the authentication process using EAP.
  3. Using EAP-TLS: The device and the RADIUS server agree to use EAP-TLS, so the device presents a client certificate to the server.
  4. Mutual Validation: The RADIUS server also presents its own certificate to the device to ensure mutual authentication.
  5. Successful Authentication and Network Access: If both certificates are valid, the RADIUS server allows access by sending an acceptance message to the access point. The device gets full access to the network.
  6. Secure Access: The device establishes a secure connection on the network, and the session can be monitored by RADIUS while the device is connected.

Example of Secure Access to Corporate Resources with Kerberos

Let’s say a user on a corporate network is trying to access a Kerberos-protected database or file server.

Step-by-Step Flow:

  1. System Login: The user logs in to their device with their credentials.
  2. Authentication Ticket Request (TGT): The device sends the credentials to the Key Distribution Center (KDC), which contains an authentication server in the domain.
  3. TGT Generation: The KDC validates the credentials and generates a Ticket Granting Ticket (TGT),which is stored locally on the user’s device.
  4. Service Access Request: When the user attempts to access the file server, their device uses the TGT to request a Service Ticket from the KDC.
  5. Service Ticket Delivery: The KDC issues a specific Service Ticket to the file server, allowing access.
  6. File Server Access: The appliance presents the Service Ticket to the file server, which validates it and grants access to the resource.
  7. Ticket Reuse: The user can access other services within the domain without authenticating again while the TGT is in effect, optimizing the user experience and security.

Building a Fortress on Access

Security in accessing networks and applications is critical for modern businesses. By adopting technologies such as Federation, SSO, and 802.1x, and protocols such as OAuth and RADIUS, a solid foundation is established for identity and access management. This strategy not only optimizes security, but facilitates an efficient user experience and enables better governance and compliance.

Thanks for reading me!!

dariocaldera Avatar

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up to receive each new topic in your email immediately.

By signing up, you agree to the our terms and our Privacy Policy agreement.