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

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

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.

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

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.

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

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.

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.

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.

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

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

Enterprise Deployment Model

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

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

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.

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

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

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

Questions?