Transcript Customer Presentation (Dark_16x9)

Microsoft Identity Solutions
Microsoft Services
Anthony Witecki, Microsoft Consulting Services
Enterprise Identity
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.
4 Pillars of Identity
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)
•Each pillar needs to be accounted for at each
access control layer
2
The Identity Pillars
Administration
Authentication
Security
• Authentication Strength
• Multi-Factor Authentication
• Authentication Delegation
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
Experience
• Disjoint Sign On
• Global Sign On
• Reduced Sign On
• Single Sign On
To Achieve SSO
• Central Issuer
• Credential Forwarding
• Protocol Transition
Authorization
Single
Multiple
Credential Credentials
DSO
GSO
RSO
SSO
Auditing
Abstraction
• Authorization hard coded into the app
• Abstract authorization away from the app
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
Coarse-Grained
• Similar to locking your front door
• Works well at the Network and Operating System layers
Fine-Grained
Role-Based
• Define tasks based on your job and group them together
Attribute-Based
• Application owns the decision based on claims about you
Policy-Based
• Decision made centrally by the enterprise
3
Single
Source
Multiple
Sources
Administration
Build an accurate view of the identity
The #1 goal of the administration pillar is to
establish that “single view” of an identity
Manage business identity rules at the
enterprise-level
There are many solutions to this when dealing
with on-premise identities:
Use a central identity management system as
the request and approval broker
• Automated Provisioning and Deprovisioning
Ensure that your business processes can to
the request and approval workflows
• Synchronization
• Manual Administration
For coarse-grained access, assign application
owners as approvers
• Self-Service
• Entitlement management
For fine-grained access, leverage the
RBAC/ABAC/PBAC system in place
4
Authentication
How much assurance is “enough”?
Disjoint Sign On
• Multiple credentials
• Multiple authenticators
Authentication Strength
•
Directory binds
•
Challenge / Response
•
Asymmetric Cryptography
Global Sign On
• Single set of credentials
• Multiple authenticators
Reduced Sign On
• Single or Multiple credentials
• Multiple authenticators
Multi-Factor Authentication
•
Assurance levels
•
Cost
Single Sign On
• Central token issuer
• Credential forwarding
• Protocol transition
Authentication Delegation
5
Authorization
Make the best decision possible
Based on your job function
Define tasks and group them together
Authorization hard-coded into the app
•
Expensive and Slow
Abstract authorization away from the app
•
Modularized operations
•
Flexibility
Based on something about you
Application owns the decision - ties attributes
to operations
Claims-based access
Similar to locking your front door
Externalize the authorization decision
Fits nicely into a SOA-based approach
Works well at the Network and
Operating System layers
Centralized
6
Auditing
Who did what, when, and how did they get access to it?
Auditing needs to be comprehensive and
occur at every layer in the access control
model
•
What was the decision and how was it
made?
At the application
•
Servers and potentially clients
Application
•
•
VPN, SSL VPN, Access Gateway
Operating System
•
•
•
Network
•
•
At the decision maker
What did the identity do?
At the entitlement source
App-specific logs and web server
logs
•
Resources
7
How long did the identity have this
attribute?
Auditing
Who did what, when, and how did they get access to it?
Ability to illustrate who approved:
Collect logs from various systems
• A new or deleted identity
• Addition or subtraction of entitlements
from an identity
Normalize the data
Who, or which, identities had access to what
service or resource and when (also who
approved that access)
Analyze data / Generate reports
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
8
What is Microsoft Doing About My Identity Crisis?
Basic
Rationalized
Dynamic
Manual Creation
Automated Creation in One
or More ID Stores
Automated Creation in All
ID Stores
Manual Deprovisioning in
All ID Stores
Manual/Automatic
Deprovisioning
Automated Deprovisioning
in All ID Stores
Identity Updates
Manual by Help Desk
Self-Service w/o
Verification
Self-Service w/ Approvals
Password Reset
Performed by Help Desk
Self-Service Password Reset
Provisioning
De-Provisioning
Administration
Standardized
No/Partial Deprovisioning
Synchronization
No Synchronization
Synchronization Among
Some ID Stores
Synchronization Among All
ID Stores
Identity Stores
No Enterprise ID Store
Enterprise ID Store +
Application Stores
Single Enteprise ID Store
Group Memberships
Manually Managed by Help
Desk
Manually Managed by Users
Request/Approval based
Groups
Sign On
Multiple Passwords,
Multiple Logons
One Password, Multiple
Logons
One Password, One Logon
Federation
No Federation
Manual Trust Configuration
Authentication Protocol
Multiple Weak Protocols
Multiple Strong Protocols,
No Transition
Multiple Protocols, with
Transition
Single Protocol
Assurance
No 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 Policies
Enforced Policies per
Application
Enterprise Policy
Enforcement
Reporting
No Reporting
Manual Collection and
Coordination of Logs
Automated Collection of
Logs
Automated Generation of
Meaningful Reports
Alerting
No Alerting
Authentication
Authorization
Auditing
9
15
POINT
INSPECTION
Attribute-Based Groups
Self-Service Trust Config
Proactive, Event-Based
Alerting
Implementation Roadmap
Provide customers with an roadmap based on customer goals and technology
capabilities
Gives an end-state vision
with incremental success
Leverage Offerings:
Enterprise Identity
Management
Enterprise Federated
Identity
Some work may
require a custom
Services engagement
Fill in the gap over
time with new offerings
10
Services Offering: Security, Identity & Access Management (SIAM)
11
Enterprise Deployment Model
Case Study in Washington State
Identity Provider
Resource Provider
Person Table
Retirement Systems
Trust
Federation Server
Federation Server
Browse
Trust
Redirect
PUBLIC
Browse
Web Application
13
Constituent Data
Enterprise
Active Directory
HRMS
Identity Provisioning
Federation Server
De-provisioning
Public
Authentication
General Requirements - Authentication
Active 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 used
Only 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 Internet
Forms-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
14
General Requirements - Certificates
Customer 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 authority
May 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 Authority
The 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 Possible
Use internally-issued certificates for the internal federation servers
Purchase trusted certificates for Proxy federation servers
15
Solution Requirements for Federation
Which Scenarios Apply?
Internal employee access
Allow 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 organization
Allow 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 organization
Use domain credentials for SSO and access to Office 365 applications
Use domain credentials for SSO and access to partner-hosted applications
16
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 engagement
Except for Office 365, SharePoint 2007, or AD RMS relying parties
Microsoft will not modify existing applications to make them claims-aware
17
Requirements for Identity Synchronization
Identity repositories must be identified and classified by integrity level
Identity attributes must be identified and matched to authoritative repositories
This becomes the Metaverse or Metadirectory
Security and distribution groups must be classified by security level
User 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
18
Questions?
20