1. Microsoft Identity Solutions
Microsoft Services
Need the Core IO for Identity & Access Management
- Better is the advanced version
AGENDA
================== 
ID Concepts (20 min)
Glossary/capability/work effort (10-15 min)
Case example as you described below, (25-35 min)
Discussion (20-30 min)
I think we need to focus this on what things do and what is needed to achieve business goals. For example:
To gain access to other systems: ADFS,
To provide common sign in: FIM or the equivalent,
To have a common GAL: GAL synch via FIM,
For web developers: Windows Identity Framework, WS-* etc…
We then dive into the administration costs of each solution:
What does it take to set it up,
What does it take to manage,
Who owns control,
Licensing, support, consulting costs
Etc
Then an example use case,
Anthony Witecki, Microsoft Consulting Services

2. Enterprise Identity Network Operating System Application Data
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.
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)
4 Pillars of Identity
Each pillar needs to be accounted for at each access control layer
Network
If you want E-Identity, these are what must be taken into account
Left side: access control layers, each of which require identity to be built into them.
Data & Application layers can be fine-grained authorization settings. SharePoint is a good example of how the application can impact the data layer, even though the data layer could be separated.
OS Layer is coarse-grained access control. Are you in the system (on/off)?
Network Layer – VPNs, direct access, etc.
IDENTITY PILLARS
These need to be applied at every layer in the stack
Operating System
Administration
Authentication
Authorization
Auditing
Application
Data

3. The Identity Pillars Administration Authentication Authorization
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
Single Credential
Multiple Credentials
Single Source
Multiple Sources
DSO
GSO
RSO
SSO
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-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
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
Drill down onto the 4As
This is a quick overview slide that will be discussed in more detail. It's being provided for your reference.

4. single view requests approvals Administration
Build an accurate view of the identity
single view
requests
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
Manage 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
approvals
Administration is identity management – it can be manual, automated or some combination thereof.
For coarse-grained access, assign application owners as approvers
For fine-grained access, leverage the RBAC/ABAC/PBAC system in place

5. experience security Authentication How much assurance is “enough”?
Disjoint Sign On
Multiple credentials
Multiple authenticators
Global Sign On
Single set of credentials
Reduced Sign On
Single or Multiple credentials
Single Sign On
Central token issuer
Credential forwarding
Protocol transition
Authentication Strength
Directory binds
Challenge / Response
Asymmetric Cryptography
Multi-Factor Authentication
Assurance levels
Cost
Authentication Delegation
Authentication is the strength of the identity
LDAP authentication is not real authentication.
1. Can I get to a directory?
2. Can I match a password stored in it?
Challenge response uses a shared secret. Verifies identity without posting password across the wire
Kerberos ticketing was the way to get secure authentication using a third party. (Carnival) – Kerberos is not an internet-friendly protocol.
Delegation is where someone else owns the identity. Could be ADFS, Passport, Facebook. Not necessarily more secure (can't require owner to do 2-factor).
Protocol Transition (constrained delegation): SAML tokens can be converted into kerberos tokens.
SSO is not a product. It's the outcome of a well architected solution.

6. role-based abstraction attribute-based coarse-grained policy-based
Authorization
role-based
Make the best decision possible
abstraction
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
attribute-based
Based on something about you
Application owns the decision - ties attributes to operations
Claims-based access
coarse-grained
Old way: embedded into the application
AzMan (Authorization Manager): good try, but failed the
Claims-based access control: gets the data to the application. It doesn't tell the app what to do with the information.
Policy-based access control (not available today). Granular. Decision on policy is given to someone else.
IT Authorize: MSIT application that reads Xactml
Need to understand how long it really takes to implement a policy-based access control solution.
policy-based
Similar to locking your front door
Works well at the Network and Operating System layers
Externalize the authorization decision
Fits nicely into a SOA-based approach
Centralized

7. many places many systems Auditing
Who did what, when, and how did they get access to it?
many places
many systems
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
At 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?
Auditing
Early use: event logs
Compliance has been driving the need for auditing
Talk about the chain of events? When did he do it? When was he approved to do it and by whom?
Auditing really needs to be driven by reporting requirements.
You must define your own requirements. Microsoft cannot tell you WHAT to implement. We can only assist with how to technically achieve it.
Challenge is still taking atomic data and making it contextual. We can look at something in the rear view mirror. Can't be done in real time at all.

8. many things decentralization Auditing
Who did what, when, and how did they get access to it?
many things
decentralization
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
Collect logs from various systems
Normalize the data
Analyze data / Generate reports
Emphasize solutions, not products. This is an industry problem, not specific to Microsoft and we don't have any products that can solve it all by itself.

9. What is Microsoft Doing About My Identity Crisis?15
POINT
INSPECTION
The process begins with a 15-point identity inspection
This is not a product. This is a solution that is focused on specific identity issues.

10. 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

11. Services Offering: Security, Identity & Access Management (SIAM)
Datacenter
Desktop
Cloud
Productivity
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
Web Protection
Mail Protection Gateway
SIAM
Secured by
The implementation road map is just one of several offerings available from Microsoft Consulting Services.
Microsoft is a product company
MCS is the solution organization within Microsoft
SIAM is a solution offering. It's not tied to any specific products

12. Enterprise Deployment Model

13. Case Study in Washington State
Identity Provider
Resource Provider
Person Table
Retirement Systems
Federation Server
Trust
Federation Server
Public
Authentication
Trust
Federation Server
HRMS
Redirect
De-provisioning
Browse
Browse
Trust
Identity Provisioning
PUBLIC
KEY POINTS 1. The left illustrates federated identity
2. The right represents identity lifecycle/management
3. Point out identity's relationship and extension beyond the directory (HRMS, Person Tables, Public Data)
Web Application
Enterprise
Active Directory
Redirect
Browse
Constituent Data

14. 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

15. 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
This slide outlines the certificate requirements for the solution. We need to ensure that the customer can meet these requirements.

16. 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

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 engagement
Except 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 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

19. Questions?