I know who you are, but you can't come in Authentication and single - - PowerPoint PPT Presentation

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
• utbound 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 using IWA ("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 Worker Grid 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

www.SAS.com