RapidIdentity Connect Security Considerations
  • 30 Mar 2022
  • 1 Minute to read
  • Dark
    Light

RapidIdentity Connect Security Considerations

  • Dark
    Light

Article Summary

Table of Contents

RapidIdentity Connect Security Considerations

RapidIdentity Connect projects are containers for a set of related resources such as Action Sets, files, job definitions, RESTPoint definitions, OAuth2 credentials, and OAuth1 consumers. They are exportable and importable as a unit (except for the OAuth credentials/consumers).

Administrative access can be granted to all projects via the Connect Admin system role. Each project also has a set of project-specific Admin roles that allow the same kind of access to individual projects.

While there is some separation between what is easily accessible at runtime from Action Sets in different projects, the boundaries are mostly superficial. Action Sets have the ability to dynamically invoke Java inside the running RapidIdentity server process. Because of this ability, it's capable of accessing anything RapidIdentity can and should be considered as privileged as a user with the System Admin role and access to the appliance's CLI menu. While there are ongoing efforts to add restrictions to some areas (and remove them in others), any user with Admin access to any Connect project and sufficient knowledge could potentially create and run Action Sets with the same access as RapidIdentity. This access includes the metadirectory, the server local file system, server CLI commands, the cluster file system, and most resources (including encrypted passwords) associated with any Connect project in the RapidIdentity cluster.

All of this together means that anyone not trusted to access any of the above should not be given Connect Admin or project-specific Admin roles. Also, that Connect projects (in their current form) are not appropriate mechanisms for delegating access to Connect to different organizations where access must be restricted to only a subset of RapidIdentity. The only way to achieve that level of separation would be to use separate Connect-only clusters configured with only the access appropriate to each organization.


Was this article helpful?