Accepted Solutions
Ken,
As Jason mentioned, customer can do this with the APIs if they are capable. If they are not someone who wants to use the APIs (which is not uncommon), there may be some creative ways to deal with this, depending on flexibility available to your user at time of auth.
Here's a non-API example that would work if your user had the ability to pick their username during authentication, even with only one AD account per user:
Since you mention that the accounts are in AD, you could leverage the Identity Rewrite function of ISE for AD and train the users to put some environment/engagement details in their logon (similar to how some MFA solutions work where you can embed tokencode at the end or beginning of a string). Here's a quick example of parsing an environment identifier such as ENV1- using "[ENVIRONMENT]-[IDENTITY[]"
This rewrite only happens just before sending the credentials to AD, so you still have the username in RADIUS request as the real raw request. Then you can put some AuthZ policies in place to give different access as a result of that parsing:
The identity rewrite happens before sending to AD so authentication is successful against AD, but you can differentiate access. Here was a test logon with ENV1-TESTER account, parsed out the TESTER to send to AD and then used the ENV1 to give the right AuthZ profile. (obviously the AuthZ rules would be more restrictive than this but just for simplicity to explain)
Again, may not be applicable in your case if user doesn't have that ability to update their username at time of authentication, and it may not be the most user friendly - but it's a different use of a built-in functionality than originally intended. Often times we can find creative ways with ISE to solve problems when we can't have customers update their internal processes/systems or if APIs are not an option for one reason or another.
Don't know if this will be acceptable, but it does work.
