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 ID/Password ID card, passport person's identity Security Token Identification Matching identity Text - based Check person to a SAS comparison against a "guest metadata identity list" Authorisation Allowing actions Grant or deny of Door unlocked, based on identity an action 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 Unchallenged sign on using IWA (Provide user id / password) ("Single sign - on") Client type Customer SAS effort Customer effort SAS effort effort "FAT"(.NET, Configure None, SAS Configure Low Java) AD + PAM sees this as Kerberos HOST "THIN" Configure Moderate (Browser) Kerberos (requires Web Auth)

Will the user have to type a password? "Challenged" "Challenged" IWA No credential Credentials stored in SAS storage profiles "FAT" (.NET, YES NO (if the user has stored NO Java) credentials in a default SAS connection profile) "THIN" Depends on browser credential caching NO (Browser) policy.

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 Facilitates SSO to most SAS servers authentication 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 Not compatible with silent launch. Prevents SSO to a standard workspace authentication 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 Control Interact Design Explore / Exploit Decide Metadata RTDM Mid Tier & Client VA Head Server Runtime RTDM Design Load and Prepare RTDM Mid Tier & Client VA Worker Grid Node Runtime RTDM Design Grid Node RTDM Client VA Worker Runtime Grid Node

Separate transactional metadata? No Yes • One place to maintain and • Independent for patching / monitor update / failure • Unified view of data lineage / • Analysts cannot impact BAU user activity transactions

Separate Visual Analytics metadata? Yes No • Independent for patching / • One place to maintain and update / failure monitor • Analysts cannot impact BAU • Unified view of data lineage / transactions user activity • VA typically has faster cadence for updates / new features