In the latest version of the Accelrys Enterprise Platform we have streamlined how permissions are managed and added the capability for packages to define groups and permission sets. In addition, enhancements have been made to File Based Authentication that make deployment of servers supporting Anonymous access easier. This session describes the new features and how to manage them through the Administration Portal.

1. (ATS4-PLAT02) New Security
Enhancements in AEP 9.0
Jon Hurley
Senior Manager, Platform R&D
Jon.Hurley@accelrys.com

2. The information on the roadmap and future software development efforts are
intended to outline general product direction and should not be relied on in making
a purchasing decision.

3. Summary
• Permissions
• Restricted Operating System Group Usage
– Only used to signal group membership
• Changes to Initial Authorization
• Recommended approach to Authorization
• Changes to File Based Authentication
• Administration
– Admin Portal
– Prototype Components
– RESTful services

4. Authentication vs. Authorization
• Authentication
– Determination of identity, i.e. who you are
– Usually provided by an external service, e.g. Active Directory
• Authorization
– Controls access to resources
– E.g. ability to use the admin portal
– E.g. access to a particular XMLDB folder

5. Roles renamed to Permissions
• Previously called roles
• But a role was really a permission to do something (e.g.
use WebPort)
• So renamed to Permission
• Permissions should be verbs
– E.g. Platform/Logon, Platform/Administration/Logon
• Groups define roles (collections of people)
– E.g. Platform/Administrators

6. Packages can define Permissions and Assignments
• Each package can define
– Groups
– Permissions
– Assignments (i.e. which groups have which permissions)
• All ‘AEP’ (aka Platform) permissions are defined in the
scitegic/generic package
• All package permissions/groups have a namespace (xxx/yyy)
– E.g. Platform/Logon – Platform is the namespace
• Permission assignments can be overwritten by the
administrator
– Will be remembered when a package is reinstalled

7. Package authorization definitions (cont)
• Namespace
– Defined in package.conf file
• Groups
– Defined in xml/objects/AuthGroups.xml
– Includes group members (e.g. Platform/Everyone is a member of
Platform/Users)
• I.e. all users are by default in Platform/Users since all users are in its
member Platform/Everyone
• Permissions
– Defined in xml/objects/AuthPermissions.xml
• Group – Permission Assignments
– Defined in xml/objects/AuthAssignments.xml

8. AEP built in Groups
• Platform/Everyone
– All users implicitly belong to this group (even if not made a direct group member)
• Platform/Users
– All general users of the AEP installation
• Platform/PowerUsers
– General user rights + ability to administer Pipeline Pilot
• Platform/Administrators
– Ability to use the Administration Portal and run administration components
• Platform/WebPort/Users
– Users that can log into WebPort (this group has the Platform/WebPort/Logon
permission)
• Platform/DeniedUsers
– Used to prevent users from logging in to AEP (the Platform/Logon permission is denied
to this group)
• On initial installation, these groups are assigned a set of the AEP permissions

9. AEP renamed Permissions
Old Name New Name
Admin Portal Platform/Administration/Logon
PPClient Platform/PipelinePilot/Logon
PPClient/Administrator Platform/PipelinePilot/Administer
Run Protocol Platform/RunProtocol
WebPort Platform/WebPort/Logon
…. Platform/Logon
• Previously roles could be ‘Allow All’
– If no explicit assignment, all users had the role
• Now permissions must be explicitly assigned
– If you haven’t been assigned the permission, you don’t have it
• If you do not have the Platform/Logon, you cannot log on to any AEP
service or application

10. AEP Platform Default Permissions
Group Members Permissions
Administrators scitegicadmin (user) Administration/Logon, Logon, RunProtocol
DeniedUsers – ~Logon
PowerUsers – Logon, PipelinePilot/Logon, PipelinePilot/Administer,
RunProtocol
Users Everyone Logon, PipelinePilot/Logon, PipelinePilot/Administer,
RunProtocol
WebPort/Users Everyone WebPort/Logon
• All groups and permissions above start with Platform/
– E.g. Platform/Administrators, Platform/Everyone,
Platform/Administration/Logon, Platform/WebPort/Logon
• All these settings can be overridden by the administrator through the
admin portal

11. Admin Portal – Authorization Pages
• Four new Authorization pages under Security
– Custom Groups
– Custom Permissions
– Group Assignment
– Permission Assignment

12. Demo

13. What are Claims?
• Claims are claims made about the user by the
authentication provider
– Operating system authentication (local or domain) provides OS
group membership
• Each OS group you belong to is a ‘claim’
– SAML Identity providers can include Assertions
• Each of these SAML Assertions is a ‘claim’

14. Future (Post 9.0) Granular Permissions
• Currently very few AEP permissions
– Platform/Administration/Logon controls the entire
Administration Portal
• Post 9.0 we intend to add many more permissions with
finer granularity of control
– E.g. Platform/Administration/ViewSettings
• Permission to view AEP settings pages
– Platform/Administration/EditSettings
• Permission to edit AEP settings (through the Administration Portal or
Administration Components)

15. Restricted Operating System Group Usage
• Previously operating system groups could be used to define
individual rights for
– Access Rights (XMLDB)
– Roles
– Data Sources
– Group Membership (AEP groups)
• Problem
– For certain authentication methods (e.g. Kerberos) can be difficult to
determine OS groups after initial login
– What do operating system groups mean for e.g. SAML assertions?
– Lack of control – IT can edit group membership without being aware
of impact on AEP installation

16. Restricted Operating System Group Usage
• Now operating system groups are only used to define
Group Membership
– We call groups (i.e. the groups defined in AEP) Group
throughout the system (administration portal and
components)
– Group memberships are determined at login (may be
determined from OS groups) and then stored with the session
– The administrator can control whether Operating System
groups are used in a particular AEP installation

17. OS Groups - Migration
• The installer provides support for legacy migration
– Consider an XMLDB Access Right, Permission or Data Source
currently referencing an OS group
• An AEP group will be created (e.g. Local_OsGroupName)
• The operating system group will be assigned to this group
• The permission/access right will be replaced with this new group
• Pre 9.0:
9.0:

18. Changes to Initial Authorization
• Previously for local/domain authentication we could specify
that a user had to belong to one or more groups in order to
log on to the platform
– This was ‘authorization’ on the ‘authentication’ page in AEP 8.5:
– Define one or more groups and the user has to belong to one of these groups
in order to login

19. Changes to Initial Authorization
• Now we define ability to log on as possessing the
Platform/Logon permission
– By default all users (e.g. the group Platform/Users) have this
permission
– Emulate old behavior by creating a group, adding members,
assigning this permission and removing from the
Platform/Users group
• Installer does this for legacy upgrades
– Always leave Platform/Logon in the Platform/Administrators
group!

20. Defaults for Platform/Logon Permission
Group Members Permissions
Platform/Administrators scitegicadmin (user) Platform/Logon, …
Platform/DeniedUsers – ~Platform/Logon
Platform/PowerUsers – Platform/Logon, …
Platform/Users Platform/Everyone Platform/Logon, …
Platform/WebPort/Users Platform/Everyone
• By default every authenticated user can log in to AEP
– Since the Platform/Everyone group is a member of the
Platform/Users group
– And the Platform/Users group has the Platform/Logon
permission

21. File Authentication – Allow File
• AEP defines an authentication mode (e.g. Domain)
• Previous versions of AEP also had a set of Administration
Portal Users

22. File Authentication – Allow File
• No longer have separate Administration Portal users
– Simply control access based on permissions
• Want to allow administrators to not be Domain accounts
– On the Authentication page, set Allow File to Yes (by default)
– Can use ‘File’ users AND other authentication mode (e.g. Domain)
• File is attempted first;
– Bad password = failure
– Unknown user = continue to normal authentication mode
• DO NOT create File users with the same name as Domain accounts
– Also facilitates anonymous access; the anonymous account can now
be a ‘File’ user not a domain account
• Of course protocols run with file accounts will not impersonate

23. Recommended approach to Authorization
• Assign permissions to groups (not users)
• Create custom groups that reflect an organization
– E.g. Accelrys Users
• Define membership in these groups
– Either through claims (e.g. OS groups)
– Or explicit user or group memberships
• Assign these groups as members to the package defined
groups
– E.g. remove Platform/Everyone from Platform/Users and replace
with Accelrys Users

24. New Authorization APIs
• Components
– Ability to write protocols to perform repetitive authorization
administration activities
• E.g. add users to AEP groups from an external database
• NOTE: these protocols must not use impersonation on Linux servers
• NOTE: these components are prototypes and will change in the next release
• RESTful Services
– A service API that lets external applications perform administration
functions
• See me for more details during the Tech Summit

25. Summary
• Revamped authorization model in AEP 9.0
• Setting the stage for future platform and applications to have
much finer grained permissions
• But for an upgrade, everything still just works…
• See the AEP Deployment guide for more information
• (ATS4-PLAT09) Kerberos and SAML with Accelrys Enterprise
Platform 9.0
– I am keen to chat with people about their plans for authentication
providers during the week