SlideShare a Scribd company logo
(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.
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
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
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
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
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
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
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
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
Admin Portal – Authorization Pages

• Four new Authorization pages under Security
   –   Custom Groups
   –   Custom Permissions
   –   Group Assignment
   –   Permission Assignment
Demo
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’
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)
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
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
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:
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
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!
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
File Authentication – Allow File

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

More Related Content

PPT
Em library
PPTX
PDF
(ATS6-GS02) Integrating Contur and HEOS
PDF
(ATS4-DEV03) Accelrys Query Service: Apps and Examples
PDF
Bridging the gap between research and it
PDF
(ATS6-DEV08) Integrating Contur ELN with other systems using a RESTful API
PDF
(ATS6-APP09) ELN configuration management with ADM
PDF
(ATS4-GS03) Partner Session - Intel Balanced Cloud Solutions for the Healthca...
Em library
(ATS6-GS02) Integrating Contur and HEOS
(ATS4-DEV03) Accelrys Query Service: Apps and Examples
Bridging the gap between research and it
(ATS6-DEV08) Integrating Contur ELN with other systems using a RESTful API
(ATS6-APP09) ELN configuration management with ADM
(ATS4-GS03) Partner Session - Intel Balanced Cloud Solutions for the Healthca...

Viewers also liked (11)

PPTX
Symyx Notebook by Accelrys and the Enterprise R&D Architecture
PDF
(ATS4-APP06) Isentris Integration with the Accelrys Enterprise Platform
PDF
Collaboration for Innovation: Enriching the Knowledge Pool
PDF
(ATS4-PLAT10) Planning your deployment for a 64 bit world
PDF
(ATS6-APP03) Thomson Rueters Content used in Acclrys Pipeline Pilot
PDF
(ATS6-PLAT05) Security enhancements in AEP 9
PDF
(ATS6-DEV04) Building Web MashUp applications that include Accelrys Applicati...
PDF
(ATS4-DEV01) Accelrys Draw Enterprise Edition is more than an end user applic...
PDF
(ATS4-GS02) A Lap Around Accelrys Enterprise Platform and Pipeline Pilot 9.0
PDF
(ATS4-APP03) Top 10 things every Notebook administrator should know
PDF
Optical properties materials_studio_55
Symyx Notebook by Accelrys and the Enterprise R&D Architecture
(ATS4-APP06) Isentris Integration with the Accelrys Enterprise Platform
Collaboration for Innovation: Enriching the Knowledge Pool
(ATS4-PLAT10) Planning your deployment for a 64 bit world
(ATS6-APP03) Thomson Rueters Content used in Acclrys Pipeline Pilot
(ATS6-PLAT05) Security enhancements in AEP 9
(ATS6-DEV04) Building Web MashUp applications that include Accelrys Applicati...
(ATS4-DEV01) Accelrys Draw Enterprise Edition is more than an end user applic...
(ATS4-GS02) A Lap Around Accelrys Enterprise Platform and Pipeline Pilot 9.0
(ATS4-APP03) Top 10 things every Notebook administrator should know
Optical properties materials_studio_55
Ad

Similar to (ATS4-PLAT02) Security Enhancements in Accelrys Enterprise Platform 9.0 (20)

PDF
Joomla Access Control List (ACL) at JoomlaDay London, UK #jduk11
PDF
User Management and Privileges on pfSense 2.4 - pfSense Hangout January 2018
PDF
Joomla! ACL - Joomla!Day Germany
PPTX
Topic 3-1_More_Linux_Commands.pptx
PDF
Joomla 1.6 ACL - J and Beyond 2011 #jab11
PDF
Joomla! 1.6 ACL at #jd10uk
PPT
e-DMZ Products Overview
PPTX
Chapter No 2 Services and Components of Operating System.pptx
PPTX
Users and groups in xp
PDF
CaseStudy_I_AnubhavSinha
PDF
aclpwn - Active Directory ACL exploitation with BloodHound
PDF
Ch2 operating-system structures
PDF
Unit+eight+ +ubuntu+security
PDF
Unit+eight+ +ubuntu+security
PDF
(ATS4-PLAT01) Core Architecture Changes in AEP 9.0 and their Impact on Admini...
PPTX
Introducing FileCatalyst Workflow
PPT
Net essentials6e ch9
PPT
Net essentials6e ch9
PDF
Beyond 'Set it and Forget it': Proactively managing your EZproxy server
PPT
operating system introduction and organization
Joomla Access Control List (ACL) at JoomlaDay London, UK #jduk11
User Management and Privileges on pfSense 2.4 - pfSense Hangout January 2018
Joomla! ACL - Joomla!Day Germany
Topic 3-1_More_Linux_Commands.pptx
Joomla 1.6 ACL - J and Beyond 2011 #jab11
Joomla! 1.6 ACL at #jd10uk
e-DMZ Products Overview
Chapter No 2 Services and Components of Operating System.pptx
Users and groups in xp
CaseStudy_I_AnubhavSinha
aclpwn - Active Directory ACL exploitation with BloodHound
Ch2 operating-system structures
Unit+eight+ +ubuntu+security
Unit+eight+ +ubuntu+security
(ATS4-PLAT01) Core Architecture Changes in AEP 9.0 and their Impact on Admini...
Introducing FileCatalyst Workflow
Net essentials6e ch9
Net essentials6e ch9
Beyond 'Set it and Forget it': Proactively managing your EZproxy server
operating system introduction and organization
Ad

More from BIOVIA (20)

PPTX
ScienceCloud: Collaborative Workflows in Biologics R&D
PDF
(ATS6-PLAT03) What's behind Discngine collections
PDF
(ATS6-PLAT09) Deploying Applications on load balanced AEP servers for high av...
PDF
(ATS6-PLAT07) Managing AEP in an enterprise environment
PDF
(ATS6-PLAT06) Maximizing AEP Performance
PDF
(ATS6-PLAT04) Query service
PDF
(ATS6-PLAT02) Accelrys Catalog and Protocol Validation
PDF
(ATS6-PLAT01) Chemistry Harmonization: Bringing together the Direct 9 and Pip...
PDF
(ATS6-GS04) Performance Analysis of Accelrys Enterprise Platform 9.0 on IBM’s...
PDF
(ATS6-GS01) Welcome
PDF
(ATS6-DEV09) Deep Dive into REST and SOAP Integration for Protocol Authors
PDF
(ATS6-DEV07) Building widgets for ELN home page
PDF
(ATS6-DEV06) Using Packages for Protocol, Component, and Application Delivery
PDF
(ATS6-DEV05) Building Interactive Web Applications with the Reporting Collection
PDF
(ATS6-DEV03) Building an Enterprise Web Solution with AEP
PDF
(ATS6-DEV02) Web Application Strategies
PDF
(ATS6-DEV01) What’s new for Protocol and Component Developers in AEP 9.0
PDF
(ATS6-APP07) Configuration of Accelrys ELN to Clone to the Latest Template Ve...
PDF
(ATS6-APP06) Accelrys LIMS and Accelrys ELN integration
PDF
(ATS6-APP05) Deploying Contur ELN to large organizations
ScienceCloud: Collaborative Workflows in Biologics R&D
(ATS6-PLAT03) What's behind Discngine collections
(ATS6-PLAT09) Deploying Applications on load balanced AEP servers for high av...
(ATS6-PLAT07) Managing AEP in an enterprise environment
(ATS6-PLAT06) Maximizing AEP Performance
(ATS6-PLAT04) Query service
(ATS6-PLAT02) Accelrys Catalog and Protocol Validation
(ATS6-PLAT01) Chemistry Harmonization: Bringing together the Direct 9 and Pip...
(ATS6-GS04) Performance Analysis of Accelrys Enterprise Platform 9.0 on IBM’s...
(ATS6-GS01) Welcome
(ATS6-DEV09) Deep Dive into REST and SOAP Integration for Protocol Authors
(ATS6-DEV07) Building widgets for ELN home page
(ATS6-DEV06) Using Packages for Protocol, Component, and Application Delivery
(ATS6-DEV05) Building Interactive Web Applications with the Reporting Collection
(ATS6-DEV03) Building an Enterprise Web Solution with AEP
(ATS6-DEV02) Web Application Strategies
(ATS6-DEV01) What’s new for Protocol and Component Developers in AEP 9.0
(ATS6-APP07) Configuration of Accelrys ELN to Clone to the Latest Template Ve...
(ATS6-APP06) Accelrys LIMS and Accelrys ELN integration
(ATS6-APP05) Deploying Contur ELN to large organizations

(ATS4-PLAT02) Security Enhancements in Accelrys Enterprise Platform 9.0

  • 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