Microsoft Services

Microsoft Identity Solutions

Anthony Witecki, Microsoft Consulting Services

2

Enterprise Identity

4 Pillars of Identity•Each pillar needs to be accounted for at each access control layer

Access Control Layers• Brokered at multiple layers in a system

• Moves from fine-grained access (data and application layer) to coarse-grained access (network and OS layer)

An identity is the sole item connecting an individual to a variety of services both on and off premises. In order to be viewed holistically, there needs to be two main elements.

Ad

min

istr

ati

on

Auth

enti

cati

on

Auth

ori

zati

on

Audit

ing

Network

Operating System

Application

Data

3

The Identity Pillars Administration

Single View• Automated Provisioning and De-provisioning• Synchronization• Manual Administration• Self-Service• Entitlement management

Requests• Manage business identity rules at the enterprise-level• Central IdM system brokers requests and approvals• Align business processes to workflows

Approvals• For coarse-grained access, assign application owners as approvers• For fine-grained access, leverage the RBAC/ABAC/PBAC system in place

Authentication

Security• Authentication Strength• Multi-Factor Authentication• Authentication Delegation

Experience• Disjoint Sign On• Global Sign On• Reduced Sign On• Single Sign On

To Achieve SSO• Central Issuer• Credential Forwarding• Protocol Transition

Authorization

Abstraction• Authorization hard coded into the app• Abstract authorization away from the app

Coarse-Grained• Similar to locking your front door• Works well at the Network and Operating System layers

Fine-GrainedRole-Based• Define tasks based on your job and group them togetherAttribute-Based • Application owns the decision based on claims about youPolicy-Based• Decision made centrally by the enterprise

Auditing

Many Places• Needs to happen at every layer• Network > VPN, SSL VPN, Access Gateway• OS > Servers and clients• Application > App-specific logs / web server logs• Resources > Various

Many Systems• At the decision maker• At the application• At the entitlement source

Decentralization• Collect logs from various systems• Normalize the data• Analyze data / Generate reports

Single Credentia

l

Multiple Credentia

ls

Single Source

Multiple Sources

DSO

GSO

RSO

SSO

4

Administration

Build an accurate view of the identitysingle view

The #1 goal of the administration pillar is to establish that “single view” of an identity

There are many solutions to this when dealing with on-premise identities:

• Automated Provisioning and De-provisioning

• Synchronization

• Manual Administration

• Self-Service

• Entitlement management

requestsManage business identity rules at the enterprise-level

Use a central identity management system as the request and approval broker

Ensure that your business processes can to the request and approval workflows

approvalsFor coarse-grained access, assign application owners as approvers

For fine-grained access, leverage the RBAC/ABAC/PBAC system in place

5

Authentication

How much assurance is “enough”?security

Authentication Strength

• Directory binds

• Challenge / Response

• Asymmetric Cryptography

Multi-Factor Authentication

• Assurance levels

• Cost

Authentication Delegation

experienceDisjoint Sign On

• Multiple credentials

• Multiple authenticators

Global Sign On

• Single set of credentials

• Multiple authenticators

Reduced Sign On

• Single or Multiple credentials

• Multiple authenticators

Single Sign On

• Central token issuer

• Credential forwarding

• Protocol transition

6

Authorization

Make the best decision possibleabstraction

Authorization hard-coded into the app

• Expensive and Slow

Abstract authorization away from the app

• Modularized operations

• Flexibility

role-basedBased on your job function

Define tasks and group them together

attribute-basedBased on something about you

Application owns the decision - ties attributes to operations

Claims-based access

coarse-grainedSimilar to locking your front door

Works well at the Network and Operating System layers

policy-basedExternalize the authorization decision

Fits nicely into a SOA-based approach

Centralized

7

Auditing

Who did what, when, and how did they get access to it?many places

Auditing needs to be comprehensive and occur at every layer in the access control model

• Network

• VPN, SSL VPN, Access Gateway

• Operating System

• Servers and potentially clients

• Application

• App-specific logs and web server logs

• Resources

many systemsAt the decision maker

• What was the decision and how was it made?

At the application

• What did the identity do?

At the entitlement source

• How long did the identity have this attribute?

8

Auditing

Who did what, when, and how did they get access to it?many things

Ability to illustrate who approved:

• A new or deleted identity

• Addition or subtraction of entitlements from an identity

Who, or which, identities had access to what service or resource and when (also who approved that access)

Any changes related to the identity object and associated approval/rejection processes

Ability to show auditors information surrounding an identities overall lifecycle

Ability to create and provide reports on the above

decentralizationCollect logs from various systems

Normalize the data

Analyze data / Generate reports

9

What is Microsoft Doing About My Identity Crisis?

Provisioning Manual CreationAutomated Creation in One or More ID Stores

Automated Creation in All ID Stores

De-Provisioning No/Partial DeprovisioningManual Deprovisioning in All ID Stores

Manual/Automatic Deprovisioning

Automated Deprovisioning in All ID Stores

Identity Updates Manual by Help DeskSelf-Service w/o Verification

Self-Service w/ Approvals

Password Reset Performed by Help Desk Self-Service Password Reset

Synchronization No SynchronizationSynchronization Among Some ID Stores

Synchronization Among All ID Stores

Identity Stores No Enterprise ID StoreEnterprise ID Store + Application Stores

Single Enteprise ID Store

Group MembershipsManually Managed by Help Desk

Manually Managed by UsersRequest/Approval based Groups

Attribute-Based Groups

Sign OnMultiple Passwords, Multiple Logons

One Password, Multiple Logons

One Password, One Logon

Federation No Federation Manual Trust Configuration Self-Service Trust Config

Authentication Protocol Multiple Weak ProtocolsMultiple Strong Protocols, No Transition

Multiple Protocols, with Transition

Single Protocol

AssuranceNo Assurance - Shared Identities

Password-Based Soft Certificates Physical Multi-Factor

Resource Authorization Application-Specific AuthZ Role-Based AuthZ Attribute-Based AuthZ Policy-Based AuthZ

Access Policies No Access Policies Written Access PoliciesEnforced Policies per Application

Enterprise Policy Enforcement

Reporting No ReportingManual Collection and Coordination of Logs

Automated Collection of Logs

Automated Generation of Meaningful Reports

Alerting No AlertingProactive, Event-Based Alerting

Authorization

Auditing

Administration

Basic Standardized Rationalized Dynamic

Authentication

15POINTINSPECTION

10

Implementation RoadmapProvide customers with an roadmap based on customer goals and technology capabilitiesGives an end-state visionwith incremental successLeverage Offerings:

Enterprise Identity ManagementEnterprise Federated Identity

Some work may require a custom Services engagementFill in the gap over time with new offerings

11

Services Offering: Security, Identity & Access Management (SIAM)

• Malware Protection

• Remote Access

• Data Protection

• Identity Management

• Federated Identity

• Public Key Infrastructure

• Network Protection

• Mail Protection and Filtering• Document Library Protection and Filtering• Rights Management• Secure Remote Access• Federated Identity

• Malware Protection

• Remote Access

• Data Protection

• Web Protection

• Mail Protection Gateway• Federated Identity• Identity Management

Secur

ed by

Enterprise Deployment Model

13

Case Study in Washington State

PUBLICWeb Application

Federation ServerFederation ServerPublic

Authentication

Browse

Redirect

Redirect

BrowseBrowse Trust

Trust

Identity Provider Resource Provider

Federation Server

Trust

Enterprise Active Directory

HRMS

Iden

tity

Pro

vis

ion

ing

De-p

rovis

ionin

g

Person Table Retirement

Systems

Constituent Data

14

General Requirements - AuthenticationActive Directory used for authentication

Can authenticate users in the same forest as the AD FS servers

Can authenticate users in trusted forests, but there must be a forest-level two-way trust in place

Non-Microsoft Identity Providers can be usedOnly Identity Providers that Microsoft has published a federation step-by-step guide for

Partner agreements and paperwork must be in place prior to deployment of the solution

Home Realm Discovery page will not be customized as part of this engagement

User authentication over the InternetForms-based authentication only

Certificate-based authentication can be used, but configuring it is outside the scope of this engagement– Customer can configure certificate authentication post-engagement if they wish

15

General Requirements - CertificatesCustomer must supply SSL certificates for the federation service

Each AD FS 2.0 server and AD FS 2.0 proxy server requires an SSL certificate:Same DNS name must be used for the subject name on every cert

Each server must have a public/private key pair

Each server is not required to use the same certificate, but they can if the issuer allows it

Can purchase the necessary certificates from a third party issuing authorityMay need to purchase multiple certificates, depending on the issuer’s policies

Wildcard or SAN certificates can be used, but are not necessary

Can issue the certificates from the customer’s Certificate AuthorityThe issuing CA must be trusted by all clients logging on to the federation service

Ideal if your clients are all “managed clients”

Not ideal if users are connecting over the internet with non-corporate computers

Hybrid Approach PossibleUse internally-issued certificates for the internal federation servers

Purchase trusted certificates for Proxy federation servers

16

Solution Requirements for FederationWhich Scenarios Apply?

Internal employee accessAllow employees to achieve SSO to federated applications when on the network

Allow employees to achieve SSO to federated applications when working remotely

Internal organization may be a large, complex multi-forest infrastructure, looking to simplify access without trusts

Sharing applications with another organizationAllow partners to use their own accounts for accessing SharePoint 2007

Allow partners to use their own accounts for accessing data protected with Active Directory Rights Management Services

Increase security by leveraging partner’s de-provisioning process

Access applications hosted by another organizationUse domain credentials for SSO and access to Office 365 applications

Use domain credentials for SSO and access to partner-hosted applications

17

Application Requirements for Federation

Applications must be claims-aware.Net applications must use Windows Identity Foundation

Non-Microsoft applications must use SAML 2.0 or WS-Federation protocols

Customer will configure relying party trusts outside of this engagementExcept for Office 365, SharePoint 2007, or AD RMS relying parties

Microsoft will not modify existing applications to make them claims-aware

18

Requirements for Identity Synchronization

Identity repositories must be identified and classified by integrity levelIdentity attributes must be identified and matched to authoritative repositories

This becomes the Metaverse or Metadirectory

Security and distribution groups must be classified by security levelUser provisioning must be mapped out

What systems are used during the entry and exit processes?

What approvals are necessary for each system?

Certificate management requirements must be defined

Questions?

20