Developer Blog

Studio Access and Administration: Who Does What?

Published March 30, 2015 by Urs

Studio

Access Control

User Management

A recent post in the Forum asked about read-only access to the Appway Studio, noting how useful it would be.

While read-only access is not available, access to the Studio can be adapted to the various use cases you may have. Whether an Administrator is permitted to undertake an activity in the Studio (such as being able to import and export files) depends on the role they have been assigned to.

If no specific roles have been assigned, then all Administrators are able to access all areas of the Studio.

Once one or more Administrators have been assigned to a role, the activities available only to that role are no longer available to Administrators not in that role.

As an example: My imaginary company, ET/CA, has decided that any and all changes to our Appway solution must first go through a specific deployment process. This company deployment process must be strictly adhered to. Therefore, we do not want any Administrators to be able to circumvent this process at any point. On the other hand, our Administrators need to be able to monitor the system and keep an eye on things at all times.

How can we achieve this?

Appway comes with a default set of roles:

For ET/CA, once our development process was finished and it was time to review and deploy the changes made, we used specific roles. We decided to assign all our Administrators to the "Console Administrator" role. Then, we assigned just one Admin to the "Deployment Administrator" and "Composition Administrator" roles.

In practice, this meant that all Administrators could view the Console and monitor our Appway solution. Only the one Admin assigned to the other roles, however, could deploy items and access the Library.

It worked... but was not exactly what we wanted. The "Console Administrator" Administrators could still access the User panel in the Studio, and administer Extensions. We decided to fine-tune our use of these roles even further.

"Super Admin"
One way to control access to the Studio on a highly user-specific level is to create one (or more) "Super Admins" who are assigned to every role. These Administrators face no restrictions in the Studio. All other Administrators, however, are only able to access the sections corresponding to the role(s) they have been assigned to.

If ET/CA chose this route, then those Administrators assigned to the "Console Administrator" role would only be able to access the Console, and nothing else. Our Super Admin, on the other hand, still has access to the whole Studio.

"Configure Additional Roles"
The other way to control access is to create roles with a specific configuration setting. In the Studio, go to Administration > System > Configuration, and choose "Edit Server Configuration" from the dropdown menu.

Add the following configuration:

"nm.auth.roles.additional = DeploymentAdministrator,CompositionAdministrator,ServerAdministrator,ExtensionAdministrator,UserAdministrator,
ConsoleAdministrator,UserAcceptanceTest,LabelManager"

Again, only Administrators assigned to a specific role are allowed to access the relevant areas of the Studio. This setup really only makes sense if you map users to roles via an LDAP integration. Otherwise, as soon as you apply this configuration with all roles, no Administrator is able to do anything anymore in the Studio: they have been effectively "locked out". Still, this configuration may also be suitable even when not LDAP-integrated: Add at least one Admin user to the User Administrator role in order for them to be able to assign other users to the remaining roles.

If ET/CA chose this route, then those Admin users assigned to the "Console Administrator" role would only be able to access the Console, and nothing else.

More information can be found in the Access Control document.

Which way do you think ET/CA should choose?

---
Image courtesy Christopher Hawkins / Flickr

Comments (0)

Developer is transitioning to Appway Community

The next step in the transition to community.appway.com is here! As of April 2017, the Community Blog is exclusively available via community.appway.com. The Blog joins the Forum and our Support system, which already moved to their new home in 2016.

Our written material (recipes and documentation) is currently being migrated, and is available in beta on community.appway.com at Support > Knowledge Base.

All information for Appway 6.3 and below is still available here on developer.appway.com while this migration takes place.

Note: Material relevant for Appway 7 will only be available in the Knowledge Base on community.appway.com

Any questions or feedback? Please contact community@appway.com