Your SlideShare is downloading. ×
  • Like
(ATS4-PLAT02) Security Enhancements in Accelrys Enterprise Platform 9.0
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 254 views
Published

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, …

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
254
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
14
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 areintended to outline general product direction and should not be relied on in makinga 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 PermissionsOld Name New NameAdmin Portal Platform/Administration/LogonPPClient Platform/PipelinePilot/LogonPPClient/Administrator Platform/PipelinePilot/AdministerRun Protocol Platform/RunProtocolWebPort 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 PermissionsGroup Members PermissionsAdministrators scitegicadmin (user) Administration/Logon, Logon, RunProtocolDeniedUsers – ~LogonPowerUsers – Logon, PipelinePilot/Logon, PipelinePilot/Administer, RunProtocolUsers Everyone Logon, PipelinePilot/Logon, PipelinePilot/Administer, RunProtocolWebPort/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 PermissionGroup Members PermissionsPlatform/Administrators scitegicadmin (user) Platform/Logon, …Platform/DeniedUsers – ~Platform/LogonPlatform/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