(ATS4-PLAT02) New Security Enhancements in AEP 9.0 Jon Hurley Senior Manager, Platform R&D [email protected]
Dec 15, 2014
(ATS4-PLAT02) New Security Enhancements in AEP 9.0
Jon Hurley
Senior Manager, Platform R&D
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