--- title: "Network user identity management" canonical: "https://docs.aryaka.com/space/KNOW/1272545378/Network%20user%20identity%20management" format: markdown --- Aryaka’s Unified SASE service includes Network User Identity Management. This feature allows you to do the following: Detect network users Control traffic to and from network users Detect network users Network users are identified using one of the following methods: Private Access login with an NCP VPN client Secure identity access portal Private Access login with an NCP VPN client Remote users that access the network using Aryaka Private Access are identified when they log in to an NCP VPN client. This login activity initiates a network event that is logged and ultimately sent to the security and routing engines on the POP, allowing a user's private IP address to be mapped to the username used to log in. The following graphic depicts this process: When a user logs in to the network using an NCP VPN client, the Private Access concentrator logs the connect event as a log line. The log line can include the following details: Connect time Public IP Private IP Username The log line is then sent to a syslog server and, from there, is written to a Kafka broker. The security engines on the POP, which control customer traffic, are subscribed to the Kafka broker and create a record to map the username and private IP of the user. When the user logs out of the network using an NCP VPN client, the Private Access concentrator logs the disconnect event as a log line. This log line can contain the following details: Disconnect time Public IP Private IP Username When the security engines on the POP receive the disconnect event log line from the Kafka broker, they delete the record of the username-private IP mapping. All security engines on the POP that the Private Access concentrator is connected to have access to this record of the user’s identity. Therefore, security rules can be written for any engine that supports user-based match criteria. Secure identity access portal Secure identity access portal uses browser-based activity to intercept network users' traffic and present them with a login page that allows them to identify themselves to the network. Network users' traffic is inspected by Aryaka security engines, as depicted in the following graphic: When network users' traffic is intercepted by the SSL engine, they are presented with a secure identity access portal login screen. The secure identity access portal allows network users to log in to the network by identifying themselves or to access the network as a guest. Depending on the option chosen, network users' traffic is then subject to all relevant security rules. To manage your secure identity access portal configuration in MyAryaka, see the Configure secure identity access portal help topic. User identity After a network user logs in to the secure identity access portal, their identity is one of the following: Known—The user successfully logs in to the network and is identified using their username. Unknown—The user cannot log in to the network or the log in attempt fails. Guest—The user opts to access the network as a guest. These user identity conditions can all be handled with user-based security rules. The rule configuration for each security engine allows administrators to write match criteria such that User = john@acme.com or User = Guest or User = Unknown . It is also possible to configure conditions such as User ! = (Unknown, Guest) . Aryaka Identity Manager To enable a network user to log in to the network, the secure identity access portal works with Aryaka Identity Manager (AIM). AIM is a centralized, integrated Aryaka service that connects to your directory service. After it is configured, AIM can perform the following actions: Obtain preconfigured lists of users and user groups. Authenticate the network user against the directory service. Redirect the network user to an external identity provider (IdP), such as Azure or Okta. AIM uses LDAP to connect to Active Directory servers and SAML or OIDC to connect to Azure or Okta. For details on how to configure AIM, see the Aryaka Identity Management help topic User identity caching Network users' identities are cached and accessible to all Aryaka security engines. Therefore, security rules can be written for any engine that supports user-based match criteria. The user’s identity remains in the user cache while they are logged into the secure identity access portal and as long as AIM has a valid access token. When the token expires, the user identity cache is flushed. You can modify the token lifespan by editing your Aryaka Identity Management configuration . Cached user identities are maintained until the user logs out or the AIM access token expires. If a user’s IP address is reassigned before either of these events occurs (for example, if the DHCP lease for the IP address expires and it is returned to the DHCP pool), the previous user’s identity could remain mapped to the IP address. You can modify the token lifespan by editing your Aryaka Identity Management configuration and you can modify DHCP leases by editing your DHCP configuration . Secure identity access portal interception When a network user attempts to access a website, for example, www.example.com , the traffic is inspected by the Next Generation Firewall (NGFW) security engine. If the NGFW engine permits this traffic, it is then intercepted by the SSL engine. However, if a network user’s traffic skips further inspection at the NGFW engine, the traffic is not intercepted by SSL and the user does not encounter the secure identity access portal. Network users can access the secure identity access portal directly by navigating to captive.aryaka.com , or administrators can set the Aryaka secure identity access portal as the default landing page of their end users' browsers. The following graphic describes the sequence of redirects and interactions that occur between the network user, Aryaka security engines, secure identity access portal, AIM, and the IdP. Bypass the secure identity access portal Some network devices or activities should not be gated by the secure identity access portal, for example, peripheral devices, such as printers and scanners, and a client application on a computer that does not use a browser-type user agent. Administrators can configure security rules to bypass the secure identity access portal for traffic that matches specific conditions, such as the following: Source zone Source IP Destination network HTTP headers Control network users' traffic MyAryaka allows administrators to control traffic for network users by configuring rules for the following security engines that support users as a match criteria: Next Generation Firewall Secure Web Gateway Anti-Malware Advanced IPS When configuring a security rule, MyAryaka queries AIM for a list of users and user groups that belong to the customer and includes them as selections in the Users match criteria. The following graphic depicts the configuration of a security rule with two users and one user group as Users match criteria: See the Security rule match criteria topic for more information about the user and user group match criteria. In this topic Related topics Configure secure identity access portal Aryaka Identity Management