Frecuently Asked Questions

Permeasyon is based on a permission delegation hierarchy. This structure reflects the actual work delegation hierarchy. Any user can be in different groups, managed by different team leaders who are the responsible people for the actual work that the user is doing. Therefore, they know the tasks that the user has to perform and the resources he is going to need to accomplish his job. These team leaders can delegate the necessary resources to their groups, as they have already been delegated to them by their leaders.

The hierarchy usually found in organizations is based on line managers, who are involved in administrative tasks such as salaries, holidays,… These managers do not manage the actual work that the user is doing and are not aware of the resources they need to access. Therefore, this structure is not suitable for hierarchical permission delegation.

Permeasyon is a Software as a Service (SaaS) application and does not require installation. It only requires an agent application in your network if your applications are not accessible from the Internet.

SCIM fails short to deliver for an access management use case as it cannot deal with specific permissions for application resources.

Permeasyon allows to quickly change member roles and add and remove new projects, with an easy and immediate adjustment of permissions.

No, you can use it just in one or more departments or organizational units in your organization. And when other departments realize the benefits of using Permeasyon, then they can start using it too.

No. Permeasyon is not an identity provider, it is an access management tool. Permeasyon manages who has access to the specific resources within applications. Identification and authentication to the applications can be done with any identity provider.

Permeasyon can be installed with its own user management or with either LDAP, SAML or OpenID Connect to be integrated with identity providers, so it can be used in most single-sign-on and multifactor authentication systems.

No. Administrators do not know the users, what they do, why they need access to a resource and when they stop needing access. The team leader is the one that really knows that and the final responsible person, he needs to confirm that the user needs access and then authorize the administrator to grant that permission. In Permeasyon, we remove this unnecessary burden to ensure an easy and immediate provisioning. Access rights are delegated, and any team leader with access to a resource can delegate that permission at the same or lower access level to groups that are below him in the hierarchy.

Any user in a parent group can remove users that are no longer working in his project at any time. To ensure the user is always removed when he leaves the company, either Human Resources or the manager can fill a leaver form when they are notified that the user is leaving, indicating when the user is leaving and the date he has to be deprovisioned. All the managers of groups that the user belongs to will be notified, so they can decide if they want to remove the user from the group in that moment to immediately remove the access to those resources or wait until the de-provisioning is automatically done. On the date set in the leaver form, Permeasyon will remove the user from all the groups and he will no longer have access to any resource.

Yes. Permeasyon allows the configuration of re-certification policies. This will create notifications asking users to check and confirm the users and permissions in the groups, to make any necessary change and then approve that all the users in the group still have access to those resources.
If the user does not perform the re-certification within a specific time, the notification will be scaled up in the hierarchy, so the next level can make a decision before the access is disabled due to the absence of approval.