Studio Access Groups

Studio Access Groups

Overview

Access Groups allows for filtering in RapidIdentity Studio. They allow for easy filtering of data to downstream consumers. Previously, data could only be filtered on a per-type basis via either mapping filters, record filters (on the schema object), or via recordStatus field mappings in the advanced settings. Unlike those methods, Access Groups live at the Studio consumer app level, meaning that you can ideally filter data access in just one location per consumer.

By default, Studio consumers are configured for unrestricted access. If toggled, all data will be accessible to the downstream consumer.

To leverage fine-grained filtering with Access Groups, the first step is to turn off unrestricted access. Once toggled off, the Add Access Group button will be active.

Note: When unrestricted access is turned off and there are no active Access Groups, no data will be accessible to the downstream consumer.

What’s in an Access Group?

Access Groups contain four major configuration fields:

• ENABLED
  • Will not be active until enabled
• NAME 
  • Name for Access Group
• START DATE
  • This date, starting at 12 AM UTC by convention, defines when the Access Group will first take effect.
• END DATE
  • This is an optional field. If blank, the Access Group will be in effect indefinitely after its start time has passed.
  • If set, this date, at 12 AM UTC by convention, defines when the Access Group will expire.
• RESTRICTION FILTERS
  • The scopes define the actual set of objects to be included for access. There will be more detail on this later.

What makes an Access Group “active?”

An Access Group is active if and only if it is both enabled and the current date range is active. If End Date is left blank, the Access Group will be available indefinitely.

Restriction Filter

The filters define the actual data you want to send for that Access Group.

• When multiple filters are added to an Access Group, they make the group more restrictive. Meaning, the filters will be treated as an AND statement.  
  • For example, if you have a set of campuses AND courses selected, then candidate records must be associated with at least one selected campus AND at least one selected course to make it past the filter.

• When multiple Restriction Filters area applied to the same Consumer App you are creating OR statements.
  • For example, if you have a set of Campuses OR Teachers Access Groups assigned to the same Consumer App, then candidate records only need to be associated with one OR the other to make it past the Restriction Filter.

There are several types of data points that can be used for a filter, including:

• Districts
  • The source for this list is the set of org records from the Provider which populates the ID Hub where orgType is equal to district.
• Campuses
  • The source for this list is the set of org records from the Provider which populates the ID Hub where orgType is equal to school.
• Courses
  • The source for this list is the set of course records from the Provider which populates the ID Hub.
• Sections/Classes
  • The source for this list is the set of section/class records from the Provider which populates the ID Hub.
• Grades
  • The source for this is the Students grade level record from the Provider which populates the ID Hub.
• Programs
  • The source for this list is a short default set, including ELL and IEP. Since programs vary widely among school districts and university systems, providing a good one-size-fits-all list is difficult.
  • Additionally, to even use these values, the programs have to be included in your data set. That is not markedly different from the other scope types above, but it is worth noting here.
• Roles
  • The source for this list is the set of roles defined in the OneRoster 1.1 Standard by default. It is the role defined in the Users file from the Provider which populates the ID Hub.