(ATS4-PLAT02) New Security Enhancements in AEP 9.0

Jon Hurley

Senior Manager, Platform R&D

Jon.Hurley@accelrys.com

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.

• 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

Summary

• 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

Authentication vs. Authorization

• 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

Roles renamed to Permissions

• 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

Packages can define Permissions and Assignments

• 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

Package authorization definitions (cont)

• 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

AEP built in Groups

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

AEP renamed Permissions

• 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

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

AEP Platform Default Permissions

• 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

• Four new Authorization pages under Security

– Custom Groups

– Custom Permissions

– Group Assignment

– Permission Assignment

Admin Portal – Authorization Pages

Demo

• 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’

What are Claims?

• 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)

Future (Post 9.0) Granular Permissions

• 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

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

Restricted Operating System Group Usage

• 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:

OS Groups - Migration

• 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

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!

Changes to Initial Authorization

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

Defaults for Platform/Logon Permission

• 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

• AEP defines an authentication mode (e.g. Domain)

• Previous versions of AEP also had a set of Administration Portal Users

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

File Authentication – Allow File

• 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

Recommended approach to Authorization

• 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

New Authorization APIs

• 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

Summary