While RSA Via Access supports using any identity source attribute in creating policies, user groups is probably the most commonly used attribute. What's great about groups is they give you pre-packaged sets of users with similar job functions. With the policies in Via Access, groups alone can offer great flexibility in access control.
Let's look at an example. Both my IT department and my Sales department need access to Concur for expenses. The Sales department has iPhones with TouchID and the IT department does not. However, the IT department has been issued SecurID tokens. As a company we want to offer single sign-on with additional authentication to Concur for all these users.
Let's take a look at how to make that happen.
First, I will create a new policy and select the appropriate identity source(s) where these users reside. Administration Console Access / Policies / Create a Policy.
To build my rule sets, I will first enable sales access by adding a new rule that selects the virtualGroups attribute.
Note: I could also use memberOf, but would need to include the full distinguished name (i.e. CN=Sales,OU=Mach_4_Corp,OU=MST,OU=United_States,OU=North_America,OU=Clients,DC=kc,DC=org ). VirtualGroups lets me strip out just the group name, "Sales".
Once I select "virtualGroups", I will select the operator "Set Contains Any" and enter the value "Sales". This says I'm restricting access to only users in the Sales group.
When I save that setting, I've allowed sales access. In order to require sales to use "Fingerprint" as the step-up method, I first need to choose step-up required. I then choose the scheme and sensitivity that I have previously mapped to Fingerprint. In this case "Basic Step-Up Authentication" with a sensitivity of "High".
Great! I've got a rule set that allows sales access if they use their Fingerprint. We're half done.
Now we need to enable IT access. To start, I will choose the option to create a new rule set. This new rule set will follow the first. Since the policy builder uses the XACML standard of First Applicable between rule sets, if I'm a user that's not in sales, the next rule set will be evaluated to see if that rule set grants me access.
I will repeat the steps I just did for selecting the attribute "virtualGroups" with the operator "Set contains any" with a value of "IT".
To add SecurID as the step-up required for the IT folks, I will again select step-up required and choose the scheme and sensitivity tied to SecurID. In this case "Basic Step-Up Authentication" with a sensitivity of "Medium".
Anyone not in sales or IT will be denied access because neither of these rules sets apply to them.
I can save this policy and then apply it to my Concur app and any other app where I want to use this policy using the application access page of application setup. Once this is done and I publish the changes, my sales team can access Concur using Fingerprint and IT can access Concur using SecurID.
