Upload
accelrys
View
252
Download
0
Embed Size (px)
DESCRIPTION
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.
Citation preview
(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