https://community.appian.com/success/w/article/3261/application-authorizationen-USTelligent Community 12https://community.appian.com/success/w/article/3261/application-authorizationTue, 23 Apr 2024 13:03:24 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:4185b491-8262-4e10-934b-03920bb91337Appian Max Teamhttps://community.appian.com/success/w/article/3261/application-authorization#commentsCurrent Revision posted to Article by Appian Max Team on 4/23/2024 1:03:24 PM<br /> <div> <h2 id="appian_objects_security_rolemaps">Appian Objects Security Rolemaps</h2> <p>Application authorization defines what artifacts, features, and user interfaces users can access. In Appian, every object has a security rolemap that specifies the different roles and actions that apply to the object. Adding users to an object rolemap allow them to perform the different actions allowed by the specified role on this object.</p> <p>For example, adding a user to the viewer role of a datastore object will allow the user to read and write data from and to all the entities (and underlying database tables) declared in the datastore.</p> <p>For more information, refer to <a href="https://docs.appian.com/suite/help/latest/object-security.html">Object Security</a>.</p> <h2 id="using_groups_and_group_memberships">Using Groups and Group Memberships</h2> <p>Users should not directly be assigned to object security rolemaps because changing what a user can see would require modifying the object configuration. It is not a dynamic setup and it would require deploying a new version of the application for every change.</p> <p>Instead, users should be members of groups which in turn are assigned to the object security rolemaps. This provides the most flexibility and allows runtime configuration of what users have access to. By adding or removing users from groups, one can change what applications or features users can access and what operations users can perform.</p> <h2 id="what_groups_to_create_to_secure_objects">What Groups to Create to Secure Objects</h2> <p>When thinking about securing an application, there are 2 categories of groups to consider:</p> <ul> <li>Application groups - These groups are used to grant high level access to applications and their underlying components. Each application should have at least 2 groups: <ul> <li>One viewer group which members have access to view and use the application.</li> <li>One administrator group which members have access to configure and manage the application.</li> </ul> </li> <li>Feature/action specific groups - These groups are used to grant access to specific features or actions in the case where access is more or less restricted than the overall application itself. For example: <ul> <li>A global record type for Customers may need to be accessible by all users. In this case, a group specific to viewing the record type needs to be created.</li> <li>An action to update the customer data may need to be restricted to a subset of users that have access to the application. As such, a group specific to this use case needs to be created.</li> </ul> </li> </ul> <p><span style="background-color:#ffff00;">In majority of cases you should not have to replicate your entire organizational structure using group hierarchies in Appian. Instead create (and/or synchronize) groups only as they are needed for configuring specific application roles or security. Similarly, there is often no need to replicate Appian application group structures in LDAP or other external directory systems.</span></p> </div><div style="clear:both;"></div> <div style="font-size: 90%;">Tags: Security</div> https://community.appian.com/success/w/article/3261/application-authorization/revision/5Thu, 18 Apr 2024 16:08:53 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:4185b491-8262-4e10-934b-03920bb91337Appian Max Teamhttps://community.appian.com/success/w/article/3261/application-authorization#commentsRevision 5 posted to Article by Appian Max Team on 4/18/2024 4:08:53 PM<br /> <div> <h2 id="appian_objects_security_rolemaps">Appian Objects Security Rolemaps</h2> <p>Application authorization defines what artifacts, features, and user interfaces users can access. In Appian, every object has a security rolemap that specifies the different roles and actions that apply to the object. Adding users to an object rolemap allow them to perform the different actions allowed by the specified role on this object.</p> <p>For example, adding a user to the viewer role of a datastore object will allow the user to read and write data from and to all the entities (and underlying database tables) declared in the datastore.</p> <p>For more information, refer to <a href="https://docs.appian.com/suite/help/latest/object-security.html">Object Security</a>.</p> <h2 id="using_groups_and_group_memberships">Using Groups and Group Memberships</h2> <p>Users should not directly be assigned to object security rolemaps because changing what a user can see would require modifying the object configuration. It is not a dynamic setup and it would require deploying a new version of the application for every change.</p> <p>Instead, users should be members of groups which in turn are assigned to the object security rolemaps. This provides the most flexibility and allows runtime configuration of what users have access to. By adding or removing users from groups, one can change what applications or features users can access and what operations users can perform.</p> <h2 id="what_groups_to_create_to_secure_objects">What Groups to Create to Secure Objects</h2> <p>When thinking about securing an application, there are 2 categories of groups to consider:</p> <ul> <li>Application groups - These groups are used to grant high level access to applications and their underlying components. Each application should have at least 2 groups: <ul> <li>One viewer group which members have access to view and use the application.</li> <li>One administrator group which members have access to configure and manage the application.</li> </ul> </li> <li>Feature/action specific groups - These groups are used to grant access to specific features or actions in the case where access is more or less restricted than the overall application itself. For example: <ul> <li>A global record type for Customers may need to be accessible by all users. In this case, a group specific to viewing the record type needs to be created.</li> <li>An action to update the customer data may need to be restricted to a subset of users that have access to the application. As such, a group specific to this use case needs to be created.</li> </ul> </li> </ul> <p><span style="background-color:#ffff00;">In majority of cases you should not have to replicate your entire organizational structure using group hierarchies in Appian. Instead create (and/or synchronize) groups only as they are needed for configuring specific application roles or security. Similarly, there is often no need to replicate Appian application group structures in LDAP or other external directory systems.</span></p> </div><div style="clear:both;"></div> <div style="font-size: 90%;">Tags: Security</div> https://community.appian.com/success/w/article/3261/application-authorization/revision/4Wed, 01 Nov 2023 17:24:58 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:4185b491-8262-4e10-934b-03920bb91337matt.cosenzahttps://community.appian.com/success/w/article/3261/application-authorization#commentsRevision 4 posted to Article by matt.cosenza on 11/1/2023 5:24:58 PM<br /> <div> <h2 id="appian_objects_security_rolemaps">Appian Objects Security Rolemaps</h2> <p>Application authorization defines what artifacts, features, and user interfaces users can access. In Appian, every object has a security rolemap that specifies the different roles and actions that apply to the object. Adding users to an object rolemap allow them to perform the different actions allowed by the specified role on this object.</p> <p>For example, adding a user to the viewer role of a datastore object will allow the user to read and write data from and to all the entities (and underlying database tables) declared in the datastore.</p> <p>For more information, refer to <a href="https://docs.appian.com/suite/help/latest/object-security.html">Object Security</a>.</p> <h2 id="using_groups_and_group_memberships">Using Groups and Group Memberships</h2> <p>Users should not directly be assigned to object security rolemaps because changing what a user can see would require modifying the object configuration. It is not a dynamic setup and it would require deploying a new version of the application for every change.</p> <p>Instead, users should be members of groups which in turn are assigned to the object security rolemaps. This provides the most flexibility and allows runtime configuration of what users have access to. By adding or removing users from groups, one can change what applications or features users can access and what operations users can perform.</p> <h2 id="what_groups_to_create_to_secure_objects">What Groups to Create to Secure Objects</h2> <p>When thinking about securing an application, there are 2 categories of groups to consider:</p> <ul> <li>Application groups - These groups are used to grant high level access to applications and their underlying components. Each application should have at least 2 groups: <ul> <li>One viewer group which members have access to view and use the application.</li> <li>One administrator group which members have access to configure and manage the application.</li> </ul> </li> <li>Feature/action specific groups - These groups are used to grant access to specific features or actions in the case where access is more or less restricted than the overall application itself. For example: <ul> <li>A global record type for Customers may need to be accessible by all users. In this case, a group specific to viewing the record type needs to be created.</li> <li>An action to update the customer data may need to be restricted to a subset of users that have access to the application. As such, a group specific to this use case needs to be created.</li> </ul> </li> </ul> <p><span style="background-color:#ffff00;">In majority of cases you should not have to replicate your entire organizational structure using group hierarchies in Appian. Instead create (and/or synchronize) groups only as they are needed for configuring specific application roles or security. Similarly, there is often no need to replicate Appian application group structures in LDAP or other external directory systems.</span></p> </div><div style="clear:both;"></div> <div style="font-size: 90%;">Tags: Security</div> https://community.appian.com/success/w/article/3261/application-authorization/revision/3Wed, 01 Nov 2023 17:24:52 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:4185b491-8262-4e10-934b-03920bb91337matt.cosenzahttps://community.appian.com/success/w/article/3261/application-authorization#commentsRevision 3 posted to Article by matt.cosenza on 11/1/2023 5:24:52 PM<br /> <div> <h2 id="appian_objects_security_rolemaps">Appian Objects Security Rolemaps</h2> <p>Application authorization defines what artifacts, features, and user interfaces users can access. In Appian, every object has a security rolemap that specifies the different roles and actions that apply to the object. Adding users to an object rolemap allow them to perform the different actions allowed by the specified role on this object.</p> <p>For example, adding a user to the viewer role of a datastore object will allow the user to read and write data from and to all the entities (and underlying database tables) declared in the datastore.</p> <p>For more information, refer to <a href="https://docs.appian.com/suite/help/latest/object-security.html">Object Security</a>.</p> <h2 id="using_groups_and_group_memberships">Using Groups and Group Memberships</h2> <p>Users should not directly be assigned to object security rolemaps because changing what a user can see would require modifying the object configuration. It is not a dynamic setup and it would require deploying a new version of the application for every change.</p> <p>Instead, users should be members of groups which in turn are assigned to the object security rolemaps. This provides the most flexibility and allows runtime configuration of what users have access to. By adding or removing users from groups, one can change what applications or features users can access and what operations users can perform.</p> <h2 id="what_groups_to_create_to_secure_objects">What Groups to Create to Secure Objects</h2> <p>When thinking about securing an application, there are 2 categories of groups to consider:</p> <ul> <li>Application groups - These groups are used to grant high level access to applications and their underlying components. Each application should have at least 2 groups: <ul> <li>One viewer group which members have access to view and use the application.</li> <li>One administrator group which members have access to configure and manage the application.</li> </ul> </li> <li>Feature/action specific groups - These groups are used to grant access to specific features or actions in the case where access is more or less restricted than the overall application itself. For example: <ul> <li>A global record type for Customers may need to be accessible by all users. In this case, a group specific to viewing the record type needs to be created.</li> <li>An action to update the customer data may need to be restricted to a subset of users that have access to the application. As such, a group specific to this use case needs to be created.</li> </ul> </li> </ul> <p>In majority of cases you should not have to replicate your entire organizational structure using group hierarchies in Appian. Instead create (and/or synchronize) groups only as they are needed for configuring specific application roles or security. Similarly, there is often no need to replicate Appian application group structures in LDAP or other external directory systems.</p> </div><div style="clear:both;"></div> https://community.appian.com/success/w/article/3261/application-authorization/revision/2Tue, 17 Oct 2023 19:38:01 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:4185b491-8262-4e10-934b-03920bb91337matt.cosenzahttps://community.appian.com/success/w/article/3261/application-authorization#commentsRevision 2 posted to Article by matt.cosenza on 10/17/2023 7:38:01 PM<br /> <h2 id="appian_objects_security_rolemaps">Appian Objects Security Rolemaps</h2> <p>Application authorization defines what artifacts, features, and user interfaces users can access. In Appian, every object has a security rolemap that specifies the different roles and actions that apply to the object. Adding users to an object rolemap allow them to perform the different actions allowed by the specified role on this object.</p> <p>For example, adding a user to the viewer role of a datastore object will allow the user to read and write data from and to all the entities (and underlying database tables) declared in the datastore.</p> <p>For more information, refer to <a href="https://docs.appian.com/suite/help/latest/object-security.html">Object Security</a>.</p> <h2 id="using_groups_and_group_memberships">Using Groups and Group Memberships</h2> <p>Users should not directly be assigned to object security rolemaps because changing what a user can see would require modifying the object configuration. It is not a dynamic setup and it would require deploying a new version of the application for every change.</p> <p>Instead, users should be members of groups which in turn are assigned to the object security rolemaps. This provides the most flexibility and allows runtime configuration of what users have access to. By adding or removing users from groups, one can change what applications or features users can access and what operations users can perform.</p> <h2 id="what_groups_to_create_to_secure_objects">What Groups to Create to Secure Objects</h2> <p>When thinking about securing an application, there are 2 categories of groups to consider:</p> <ul> <li>Application groups - These groups are used to grant high level access to applications and their underlying components. Each application should have at least 2 groups: <ul> <li>One viewer group which members have access to view and use the application.</li> <li>One administrator group which members have access to configure and manage the application.</li> </ul> </li> <li>Feature/action specific groups - These groups are used to grant access to specific features or actions in the case where access is more or less restricted than the overall application itself. For example: <ul> <li>A global record type for Customers may need to be accessible by all users. In this case, a group specific to viewing the record type needs to be created.</li> <li>An action to update the customer data may need to be restricted to a subset of users that have access to the application. As such, a group specific to this use case needs to be created.</li> </ul> </li> </ul> <p>In majority of cases you should not have to replicate your entire organizational structure using group hierarchies in Appian. Instead create (and/or synchronize) groups only as they are needed for configuring specific application roles or security. Similarly, there is often no need to replicate Appian application group structures in LDAP or other external directory systems.</p><div style="clear:both;"></div> https://community.appian.com/success/w/article/3261/application-authorization/revision/1Thu, 31 Aug 2023 19:11:47 GMTd3a83456-d57b-489c-a84c-4e8267bb592a:4185b491-8262-4e10-934b-03920bb91337joel.larinhttps://community.appian.com/success/w/article/3261/application-authorization#commentsRevision 1 posted to Article by joel.larin on 8/31/2023 7:11:47 PM<br /> <p>temp</p><div style="clear:both;"></div>