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, we have added support for enterprise authentication solutions like Kerberos and SAML and improved the usability of the Administration Portal. This session describes the new features and how to manage them through the Administration Portal.

1. (ATS6-PLAT05) Security
enhancements in AEP 9
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. • Security
– Authentication
– Authorization
– Session Security
• Administration Portal
– Home Page
– Extensible WAF container
– New and updated Security pages
Content

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

5. Authentication
• New Authentication Providers in AEP 9.0

6. • AEP can use an external authentication service
– Local or Domain authentication
– ‘File’ authentication can be enabled
independently
– SSL can be required
• File authentication active with other methods
– File is attempted first, then external service
– DO NOT create File users with the same name as
Domain accounts
• Anonymous account can be a ‘File’ or a domain
account
– Protocols run with file accounts will not
impersonate
• Administration portal uses standard
authentication
– Platform/Administration/Logon permission
required
Authentication

7. • Kerberos Delegation on Windows
– Full or Restricted Impersonation
– Protocols can use their Kerberos
token to connect to other
Kerberized resources (e.g. UNC
files, HTTP services, SQL Server
databases)
– Requires AEP server configured for
Impersonation and the Kerberos
realm (e.g. Active Directory)
configured to allow Delegation
• Kerberos Authentication on Linux
– Kerberos authentication is now
supported on Linux
– Delegation is NOT supported on Linux in
AEP 9.0
• Kerberos requires clients that support
SPNEGO
– Web browsers: IE, Firefox, Chrome
– Windows SDKs:
• .NET Client SDK, JavaScript Client SDK, C
Client SDK, RunProtocol
– Not supported: other SDKs (Java), Linux
SDKs or Pipeline Pilot client
Enhanced support for Kerberos/SPNEGO

8. • Kerberos is ticket based authentication
baked into the Operating System
– Many components (e.g. Web Browsers)
are able to transmit Kerberos tickets
• Provides Single Sign On – if you are already
signed on to the browser, the Kerberos
ticket can log you in to another system
– The server requests an ‘authentication
negotiation’ with the browser
• If the browser (and OS account) is
appropriately configured, a Kerberos ticket
can be transmitted in response
• Kerberos requires clients that support
SPNEGO:
– Web browsers: IE, Firefox, Chrome
– Windows SDKs: .NET Client SDK, JavaScript
Client SDK, C Client SDK, RunProtocol
– Not supported: other SDKs (Java), Linux
SDKs or Pipeline Pilot client
What is Kerberos?

9. AEP Authentication Providers
Authentication
Provider
8.5 9.0
Windows Linux Windows Linux
File Y Y Y Y
Local Y Y Y Y
Domain Y Y Y Y
Kerberos Y Y Y
Kerberos
w/delegation
Y
SAML
Sender Vouches
Y Y
Changes for 9.0
• Kerberos on Linux
• Kerberos delegation on
Windows
• SAML Sender Vouches
– SOAP-based
– Inbound/Outbound
• File authentication active
with other methods
• Administration portal uses
standard authentication
New for 9.0

10. • SAML is Security Assertions Markup Language
– Commonly associated to SOAP services
– SAML allows federation of multiple Identify Providers (IdP)
• Often used in externalization scenarios to link IdPs across companies
• SAML Sender Vouches Sender Confirmation in AEP 9
– Web Services securely calling AEP
– AEP securely calling SAML protected Web Services
SAML Support

11. Outbound SAML Sender Vouches
Inbound SAML Sender Vouches
Inbound/Outbound SAML Support
SAML
Kerberos
Username
Custom Cookie
ServiceContainer
WebLogic
Server
Other
Server
SAML
Kerberos
Form Based
Basic
AEP 9.0
Server
Browser
IE, FF,
Chrome
Other
Clients
SAML
Kerberos
Form Based
Basic
ServiceContainer
WebLogic
Server
Other
Server
SAML
Kerberos
Form Based
Basic
AEP 9.0
Server
Browser
IE, FF,
Chrome
SDKs
CALPP,
NALPP, JALPP

12. Authorization
• Changes to permissions, groups
• Greater support for package specification

13. AEP 9.0 Security Model
Goals
• Implement scalable model
– Assignment via APIs
– Envision thousands of
permission assignments
• Standardize terminology
– Groups, Users, Permissions
• Establish extension points
– Packages can manage their own
security
Changes from 8.5
• Roles renamed to Permissions
– Role was really a permission to
do something (e.g. use
WebPort)
• All assignment happens
against AEP users/groups
– OS groups cannot be used
directly
• Packages can define Groups,
Permissions, and Assignments

14. • Permissions should be verbs
– E.g. Platform/Logon,
Platform/Administration/Logon
• Groups are used to define roles
– E.g. Platform/Administrators
• 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
• NEW: If you do not have the Platform/Logon,
you cannot log on to any AEP service or
application
8.5 Role Name 9.0 Permission 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
Permissions

15. 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 Built-In Groups:
– Platform/Everyone
• All users automatically belong to this group
– 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
– Platform/DeniedUsers
• Used to prevent users from logging in to AEP
Default ‘Platform’ Permission Assignments
All group and permission names above start with Platform/
(E.g. Platform/Administrators, Platform/Everyone,
Platform/Administration/Logon, Platform/WebPort/Logon)

16. • In 8.5 (and earlier) we could specify
that a user had to belong to one or
more groups in order to log on to
the platform
– If groups were specified, user has to
belong to one of these groups to
login
– This was ‘authorization’ on the
‘authentication’ page
• In 9.0, the Platform/Logon permission
controls the ability to log on to AEP
– By default all users (e.g. the group
Platform/Users) have this 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
• IMPORTANT: Always assign
Platform/Logon to the
Platform/Administrators group!
Logon Authorization

17. Additional Details
Packages
• Each package can define
– Groups
– Permissions
– Assignments (i.e. which groups have which
permissions)
• Permission assignments can be overwritten by
the administrator
– Will be remembered when a package is
reinstalled
• Package developers can use/extend the AEP
Authorization Model
– Define their own groups and permissions
– Within protocols, use the ‘Check User Has
Permission’ and ‘Check User Is Group Member’
components to restrict access
OS Group Usage
• In 9.0, 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
• The installer will migrate OS group
security settings to the AEP 9 security
model

18. Session Cookie
• Security Enhancements

19. • Restrict session cookies to a server
– Additional encryption key
– Session cookie can only be used on servers with the same key
– Set ‘Session Salt’ in Server Configuration to activate
• Leave empty to retain 8.5 behavior
• Non-persistent session cookies
– Delete cookie when browser is closed
– Set ‘Retain session cookie beyond web browser session’ to No
• Set to Yes to retain 8.5 behavior
• Restrict cookie use to secure connection
– Set ‘secure’ flag on cookies if SSL-only mode
• Do not set SSL-only to retain 8.5 behavior
Session Cookie Security Enhancements

20. Administration
• What’s new in the Administration Portal

21. • Home Page
– Orient the administrator
– Shortcuts to common and
recently used pages
• Extensible WAF container
– Applications can add their
own administration pages
– Pages can be protected by
permissions
Administration Portal Highlights

22. • New and updated Security
pages
– Authentication
– Groups
– Permissions
– SAML
• Consolidated server
information pages (Tomcat,
Apache, etc.)
• Refreshed existing pages for
consistency
Administration Portal Highlights

23. DemoAdministration Portal
• New Administration Portal Home Page
• Sample Security Pages

24. • In this session we reviewed new security and administration
features in 9.0
– Authentication methods
– Authorization model
– Session security
• More detailed information is available
– Kerberos/SPNEGO
– SAML
– Package development and the permissions model
– ATS6-DEV09 – Discussion of the SOAP Connector accessing SAML Sender
Vouches protected SOAP Web Services
Summary