Authorization policies using certificates

[raksec]

Hello Experts,

The requirement is to provide different level of access to employees/contractors based on the department/BU they belong to. The employees/contractors would fall into different groups, e.g. employee1, employee2, contractor1, contractor2, and so on.

Customer doesn't have an AD. They have Okta, but ISE-Okta integration doesn't provide user group details to ISE so we can't have authorization policies based on user group membership.

In this case, we are thinking to use certificates to not only authenticate, but also to authorize employees/contractors. Customer agreed to deploy an internal Certificate Authority. However, before we proceed I wanna check the possibilities. We wanna use certificate attributes to provide different level of access to different user groups. How flexible and scalable is the solution? Any suggestions or recommendations?

Thanks,

Rakesh Kumar

[AndreaTornaghi]

Hi, 

basically you could think to apply different AuthZ policies based on CN.

If you use different CN for each department you can think to use this attribute for assigning different AuthZ result.

CN could be based on the hostname of the client.

Kind Regards

[Mike.Cifelli · Accepted solution]

As @AndreaTornaghi mentioned for Authz you have the ability to utilize several unique identifiers based on cert attributes.  From a pki perspective you could potentially manage different cert templates for each group.  For Authc you could use a CAP with the identity store set to 'not applicable'.  Essentially Authc would only occur based on trusted certs.  Then rely on Authz conditions to push policy based on unique identifiers.  

[raksec]

Thanks Mike and Andrea.
So on authentication part, if we integrate ISE with internal CA, would ISE be able to validate user's certificates?

Second, I can find the requirements for CA to interoperate with ISE in compatibility guide. However, how about this case? Is this enough if I say that X.509 certificates issues by internal CA should be in Privacy-Enhanced Mail (PEM) or Distinguished Encoding Rule (DER) format?

[Mike.Cifelli]

You will need to ensure that the cert chain is in the ISE trust store. There is an Authz condition that looks like this that could be referenced: NetworkAccess:AuthenticationMethod EQUALS x509_PKI. Again, I would look into using unique identifiers to differentiate the groups. Check out the CERTIFICATE authz conditions for more detail on your available options.

[raksec]

Thanks Mike.

My question was on compatibility of ISE with a Certificate Authority. Customer has to choose a CA solution to deploy with the help of a third party. However, I have to make sure that the CA solution they choose should be compatible with ISE. Any suggestions on this part?

I found some info in ISE compatibility guide:
https://www.cisco.com/c/en/us/td/docs/security/ise/2-6/compatibility/b_ise_sdt_26.html#requirementsforca

Is the info provided by the link relevant to the requirement?

[Mike.Cifelli]

The info in the link is relevant. Few things to note are: I would not rely on ISE as an enterprise CA solution. Pretty sure Cisco docs state that too. In my experiences Microsoft Active Directory Certificate Services is typically the third party ideal/preferred solution. However, this will vary upon customer requirements. I have managed several internal MS-AD CS pki, and have found it to be straightforward & easy to manage. Easy from the viewpoint of being able to manage certain components such as auto-enrollment via GPOs. HTH!

[Jason Kunst]

---

@Mike.Cifelli wrote:
The info in the link is relevant. Few things to note are: I would not rely on ISE as an enterprise CA solution. Pretty sure Cisco docs state that too. In my experiences Microsoft Active Directory Certificate Services is typically the third party ideal/preferred solution. However, this will vary upon customer requirements. I have managed several internal MS-AD CS pki, and have found it to be straightforward & easy to manage. Easy from the viewpoint of being able to manage certain components such as auto-enrollment via GPOs. HTH!

---

that's correct, its only meant to produce certificates for clients authenticating to ISE (pxgrid clients, endpoints doing BYOD, and those endpoints that can't do BYOD (linux, iot, etc) but can onboard manually using the certificate provisioning portal). Its not meant for items like your web servers,etc

[raksec]

Thanks Jason and Mike.