Embed Size (px)
Citation preview
I know who you are, but you can't come in
Authentication and single sign-on in the SAS platform
Agenda
• Authentication
• Inbound authentication
• Outbound authentication
• Single Sign-on
Definitions
Stage Process Method Physical world
Authentication Verifying a
person's identity
ID/Password
Security Token
ID card, passport
Identification Matching identity
to a SAS
metadata identity
Text - based
comparison
Check person
against a "guest
list"
Authorisation Allowing actions
based on identity
Grant or deny of
an action
Door unlocked,
gate opened
A user will go through all three phases when using SAS
We will only deal with authentication today
Authentication
Authentication
Inbound Authentication:
Initial Connection to a Metadata server
SAS Internal Authentication
Internally authenticated SAS accounts are special purpose accounts. They cannot launch OS
processes such as Workspace servers under their own identity. Examples of internal accounts are
sasadm@saspw - Used for SAS metadata administration
sastrust@saspw -Used for SAS server to SAS server communication
Inbound authentication
Credential based
Direct Authentication
Authentication
Outbound Authentication:
Connecting to a resource in the SAS
environment
Outbound Authentication
• Outbound authentication is establishing a
connection to a server after initial authentication
to the metadata server
• Inbound authentication is a pre-requisite of
outbound authentication.
Recap: inbound authentication
Outbound authentication to a standard
workspace server
Outbound authentication to a standard
workspace server
Outbound authentication to a standard
workspace server
What is a "standard" workspace server?
Credential Management
Method
Re-use (credential caching) The credentials used to authenticate
to the metadata server are presented
to the new server
Retrieve Credentials associated with
- The user or a user's groups
- The server's authentication domain
Are retrieved from the metadata server
and presented to the new server
Request The user is presented with a prompt
and asked to provide a user ID and
password
SAS Authentication domains
SAS Authentication domains
Credential Management
SAS token authentication
The metadata server generates and validates a single-use identity token for each authentication event.
This has the effect of causing participating SAS servers to accept users who are connected to the
metadata server.
SAS token authentication
Scope Primarily used for metadata-aware connections to the stored process server, the
server-side pooled workspace server, the OLAP server, the content server, and (in a
specialized configuration) the standard workspace server.
Also used by launched servers to connect back to the metadata server (for example,
from the workspace server to the metadata server for library pre-assignment).
Benefits Preserves client identity for metadata layer access control and auditing purposes.
No individual external accounts are required, no user passwords are stored in the
metadata, and no reusable credentials are transmitted.
Limits On the workspace server, reduces granularity of host access.
Supported only for metadata-aware connections (in which the client learns about the
target server by reading the server's metadata definition).
Use Optional for the workspace server, otherwise mandatory in certain configurations
Integrated Windows Authentication
Web Authentication vs. SAS authentication
Single Sign-on
Single sign - on two definitions
• 1. Challenged access, but one password which
works everywhere
• 2. Unchallenged access to resources *
• Thick Client (Java, .Net)
• Thin client (browser)
• External data (Oracle, Teradata, Hadoop….)
*This is the default definition used in a SAS architecture design
Setup Effort
Challenged sign on
(Provide user id / password)
Unchallenged sign on usingIWA ("Single sign - on")
Client type Customer effort
SAS effort Customer effort SAS effort
"FAT"(.NET, Java)
Configure AD + PAM
None, SAS sees this as HOST
Configure Kerberos
Low
"THIN" (Browser)
Configure Kerberos
Moderate (requires Web Auth)
Will the user have to type a password?
"Challenged"No credential storage
"Challenged"Credentials stored in SAS profiles
IWA
"FAT" (.NET, Java)
YES NO (if the user has stored credentials in a default SAS connection profile)
NO
"THIN"(Browser)
Depends on browser credential caching policy.
NO
Summary for Single Sign On
Feature Notes
Internal authentication An internal account cannot participate in IWA or web authentication and cannot
launch any OS processes (e.g. standard workspace servers)
SAS token
authentication
Facilitates SSO to most SAS servers
IWA Facilitates silent launch of desktop applications. If not fully configured, prevents
SSO to a standard workspace server. Requires a Kerberos implementation.
Web authentication Facilitates silent launch of web applications. Prevents SSO to a standard
workspace server (as the user is not required to have have an OS account on
SAS servers).
Direct LDAP
authentication
Not compatible with silent launch. Prevents SSO to a standard workspace
server
PAM Can help unify authentication
Credential Management Facilitates SSO to third-party servers and (in some configurations) workspace
servers.
Why all these Metadata Levels?
Content
• What is a metadata level
• How is a metadata level created
• How are they separated
• What metadata levels are for
• What metadata levels aren't for
• How to move content between levels
• Where metadata levels can touch
What is a metadata level?
• A SAS environment separated physically or
logically from other SAS environments
How are metadata levels created?
• Each metadata level is separately installed
• Option of cloning and using the host name
change utility?
How are metadata levels separated?
• For each process, the combination of port
number and host name must be unique
• Same host, different ports
• Different host, same or different ports
What metadata levels are for
• Control changes to content in a rational manner
• Isolate ad-hoc development work and testing
• Minimise disruption to the production environment
• Support the development lifecycle (route to live)
• Typically 3 levels (Development > Test > Production)
• Normally numbered sequentially Lev3 > Lev2 > Lev1 (production is level 1)
• The level number is determined at installation
• Final digit of port numbers will generally reflect the level number
• e.g. metadata server in Lev1 uses port 8561, Lev2 uses 8562 etc.
• Can be many more levels (Dev > Test > Unit Test > Prod > Patch Test)
• May also have a "level zero" for real - time decisioning
What metadata levels are not for
• Separation of departments within an organisation
• Applying security restrictions
• High availability
• Disaster recovery
How to move content between levels - 1
• Export ("zip up") a package in the source level
• Import ("unzip") a package in the target level
• Packages can be moved to / from any level
• System metadata - e.g. server definitions - can be packaged (SAS 9.3 or later)
• Package contents can be filtered during import / export
• Name
• Type
• Date created / Date modified
• Select / Deselect individual items
How to move content between levels - 2
• Values (e.g. physical names, port numbers) can be modified during import
• Many other options e.g.
• Include dependent items
• Include physical data with table metadata
• Include empty folders (use to create a template for folder structures)
• Import new objects / Overwrite existing objects
• Include Access Controls
Example of dependent items
• This Data Integration Studio job describes required processing
• The processing depends on the tables but they are not "process" so
are not packaged by default
• Including dependent objects adds the table metadata to the package
• Additionally, the data can now be included.
Packaging a job
Include Physical Table
• Caution: This option
can create huge
package sizes
Metadata levels can share resources via SAS grid
SAS Grid
"Level zero" - real - time decision
Design Decide
Load and Prepare
Control
Mid Tier &
RTDM Design
RTDM
Runtime
Mid Tier &
RTDM Design
RTDM
Runtime
RTDM
Runtime
Metadata
Server
Explore / Exploit
VA Head
VA Worker
VA WorkerGrid Node
Interact
Client
Client
Client
Grid Node
Grid Node
Separate transactional metadata?
No
• One place to maintain and
monitor
• Unified view of data lineage /
user activity
Yes
• Independent for patching /
update / failure
• Analysts cannot impact BAU
transactions
Separate Visual Analytics metadata?
No
• One place to maintain and
monitor
• Unified view of data lineage /
user activity
Yes
• Independent for patching /
update / failure
• Analysts cannot impact BAU
transactions
• VA typically has faster cadence
for updates / new features
What happens where
Lev3
Dev
Lev2
Test
Lev1
Prod
Lev0
Real Time
ETL Flows Create Test Use
OLAP Cubes Create Test Use
Stored Processes Create Test Create/Test/Use
Statistical Models Create/Test/Use/Manage
Reports / Explorations Create/Test/Use
Real Time Decisioning Create/Test Use
Patch testing Test Deploy Deploy Deploy
Questions
