Skip to main content
What access does BRM need? BRM needs view access for the user directory and audit logs in your IAM systems. For Okta, this is specifically requesting permission for the okta.users.read, okta.apps.read, okta.logs.read scopes. For Google, this is specifically requesting permission for the reports.audit.readonly and directory.user.readonly scopes. Specifically what data is BRM ingesting and storing? BRM is only ingesting authentication and revoke logs from these systems. When users in your org authenticate into an application that your IAM system has (e.g. Salesforce), a log with the user ID and timestamp is created. BRM aggregates these logs to provide you digestible app utilization data. Can BRM change the permissions it has access to? You, as the Google or Okta admin, are fully in control with what permissions to provide to BRM.
BRM’s access will never expand or change without you as the Okta admin changing the permissions it provides BRM.
Does BRM have access to our login credentials? BRM never reads or stores your Okta login credentials (user/password). That information is never provided to BRM and BRM will never be able to login to your Okta instance. How far back are you looking historically? Upon initial sync, BRM will do the following for Google/Okta
  • For Google, BRM will look back up to 6 months worth of data. This is the longest timeframe in which Google will retain audit report data.
  • For Okta, BRM will look back up to 3 months worth of data. This is the longest timeframe in which Okta will retain authorization logs.
Once initial sync is complete, BRM will update this data every 15 minutes going forward. As you use BRM over time, you’ll build up more historical data than your IAM system will even save for you.