Home > Articles > Network Technology > General Networking > Authentication and Authorization Policies: Using Cisco Identity Services Engine in a BYOD World

Authentication and Authorization Policies: Using Cisco Identity Services Engine in a BYOD World

Chapter Description

This chapter examines the relationship between authentication and authorization and how to build policies for each, describing a few common Authentication Policies and Authorization Policies to help you see how to work with these policy constructs.

Authentication Policies

Authentication policies have a few goals, but the ultimate end goal of an Authentication Policy is to determine if the identity credential is valid or not.

Goals of an Authentication Policy

Authentication Policies have a few goals:

  1. Drop traffic that isn’t allowed and prevent it from taking up any more processing power.
  2. Route authentication requests to the Correct Identity Store (sometimes called a Policy Information Point [PIP]).
  3. Validate the identity.
  4. Pass successful authentications over to the Authorization Policy.

Accept Only Allowed Protocols

By default, ISE allows nearly all supported authentication protocols. However, it would behoove the organization to lock this down to only the ones that are expected and supported. This serves a few purposes: keep the load on the Policy Service nodes down and use the Authentication Protocol to help choose the right identity store.

Route to the Correct Identity Store

Once the authentication is accepted, ISE makes a routing decision. The identity store that should be checked is based on the incoming authentication. Obviously, if a certificate is being presented, ISE should not try and validate that certificate against the internal users database.

If your company has multiple lines of business, it may also have more than one Active Directory domain or more than one LDAP store. Using attributes in the authentication request, you can pick the correct domain or LDAP store.

Validate the Identity

Once the correct identity store has been identified, ISE confirms the credentials are valid. If it’s a username/password, do those match what is in the directory store? If it’s a certificate, does ISE trust the certificate signer? Was that certificate revoked?

Pass the Request to the Authorization Policy

If the authentication failed, the policy can reject the request without wasting the CPU cycles comparing the request to the Authorization Policy. Also, if the request did not match any of the configured rules, should a reject message be sent? However, when the request passes authentication, it is now time for the hand-off to the Authorization Policy.

3. Understanding Authentication Policies | Next Section Previous Section