Service Management and Using Grouper for Enhanced Access Control and Provisioning
CONVENER: Andrea Harrington and Rob Carter
SCRIBE: Nick Roy
# of ATTENDEES: ~30
MAIN ISSUES DISCUSSED: Service Management for IAM, Grouper for Service Provisioning and Enhanced Access Control
ACTIVITIES GOING FORWARD / NEXT STEPS: Interested parties in enhanced service provisioning using Grouper contact Rob Carter
Service Management and Grouper-Based Service Provisioning (Santa Cruz, 3:15)
Andrea Harrington - service management processes for IdM, shared services, SLAs, etc.
-About 50% of the room said they had established IAM service management practices
-About same number said they had a published IAM service catalog
-Mixed response about uptake of IAM services by customers
Trying to determine how best to spend time on enhancing service management - is it documentation that people want?
Discussion of using a troubleshooting rubric that customers can use to troubleshoot their IAM problems themselves, walk them through the steps, help them find what might be broken. Bulk of the service desk calls are people who have a lot of common and solvable types of problems. There are thousands of these types of calls, so goes well for IAM people but not necessarily for the service desk reps.
Try to send all customers through tier 1 so that there is a common point of contact. Problem comes when people get ahold of a direct line into someone in direct support of the service, then bypasses the service desk.
Different categories of service requests:
Data quality/understanding/documentation vs. authN issues. 90% of calls are related to questions about the data, then do troubleshooting. Example: person not in group because they were hired 3 days ago and appointment hasn’t fully propagated yet.
Types of tools for diagnostics - SQL views, shell scripts, web sites that are user-friendly for the 1st and 2nd tier service desk reps. Creating user-friendly web apps for diagnostics pays large dividends.
Poll of IT shops that use ServiceNow - about 80% of the hands in the room.
Question of how KB articles are used - trend toward just referring customers to KB articles? Sometimes linked to, but generally with context wrapped around it.
How much documentation is the right amount to have out there for customers to be able to do troubleshooting? Are business rules published? Internally? Publicly?
One person said she realized that business rules are not at all transparent, but need to get them published and figure out how to get people to read them/want to read them/understand them.
If you publish them, people will read them, start asking questions.
Discussion of a toolset or guide that would walk IAM customers through how to integrate with IAM correctly, and to document what they are doing and how they are using IAM data.
-
Rob Carter - Large IAM system at Duke - accumulated, large body of data that they use to deal with all kinds of things including provisioning, authorization, etc. But haven’t had lots of departments or services outside the central IT org use their identity data. How do they get more buy-in to achieve the service model they want. Trying to solve an authZ problem related to allowing access to different types of identity data, without relying on app programmers to "just do the right thing" and also without the IAM shop having to write custom access control for each application that needs to consume the data.
The identity data is out there, but people can’t take advantage of the data because either they can’t use LDAP, don’t understand the data, afraid of using it, etc. Not entirely confident that they are doing the right things to protect the data for each specific use of the data. Then when some policy changes or authZ rule changes, have to scour thousands of lines of code to determine the impact.
Let’s say there are ~400 identity attributes scattered across various systems - OIM, LDAP directories, SQL databases. Not entirely that are applying authZ rules equally across all systems where attributes are published.
One idea: put a web service on top of that stuff - attribute service - allows insulation of the customer/caller from the backend systems, allows common authZ rules, etc. Basically a virtual directory but via web service context instead of a directory.
Also have considered adding in a virtual directory to expose the web service as an LDAP directory, to allow the things that can speak LDAP to continue to allow LDAP-consuming apps to use the model. There are also some contexts that need to interact with this data to communicate. Many programmers in other types of systems don’t understand the information in other systems or how to deal with IAM systems. Have thought about how to present the IAM data in ways that the ERP programmers can work with.
Problem: Only place they can put the strong authZ stuff is in the directories (ACIs), but don’t want to keep all of the data there. Would like to pare ACIs down. So what if they leverage Grouper for authZ via the attribute/object service. So - build authZ web service that consumes information from Grouper and can apply authZ/act as a Policy Decision Point for the attribute service. They would like to encode granular attribute information to control who and what can access attributes, attribute values and relationships between people. Encoding that data could get very complex. One example: Guest system/sponsored identities. The guest system and the users of the guest system need to have access to different attributes depending on the relationship of the person using the system to the guest account (sponsor, etc.)
Thinking of using Grouper permissions to encode a hierarchy of actions that encode both actions and attributes: [read sensitive data]. Then have resources that can be hierarchies of users or groups or other things. Then allow the security office to manipulate the action permissions to align with data categorization schemes. Example: Employee who is a payroll clerk can read sensitive information for employees who are in the same department as them. Use limits to enforce relationship rules, etc. Because I’m a sponsor of your account, I’m allowed to update certain information about you in the guest system. All of that stuff will get rolled up via a web service that could protect the attribute/object web service. Could extend this model to resources like doors, and actions like lock/unlock/etc. Allow physical security people to manage some of that information through grouper.
Could also encode provisioning rules as permissions. Make the action "can be provisioned" or "should be provisioned"
Penn State would be interested in using this/helping out with it.