Presentation on theme: "Microsoft Identity Solutions"— Presentation transcript:
1Microsoft Identity Solutions Microsoft ServicesNeed the Core IO for Identity & Access Management- Better is the advanced versionAGENDA================== 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 costsEtcThen an example use case,Anthony Witecki, Microsoft Consulting Services
2Enterprise 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 LayersBrokered at multiple layers in a systemMoves from fine-grained access (data and application layer) to coarse-grained access (network and OS layer)4 Pillars of IdentityEach pillar needs to be accounted for at each access control layerNetworkIf you want E-Identity, these are what must be taken into accountLeft 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 PILLARSThese need to be applied at every layer in the stackOperating SystemAdministrationAuthenticationAuthorizationAuditingApplicationData
3The Identity Pillars Administration Authentication Authorization Single ViewAutomated Provisioning and De-provisioningSynchronizationManual AdministrationSelf-ServiceEntitlement managementRequestsManage business identity rules at the enterprise-levelCentral IdM system brokers requests and approvalsAlign business processes to workflowsApprovalsFor coarse-grained access, assign application owners as approversFor fine-grained access, leverage the RBAC/ABAC/PBAC system in placeAuthenticationSecurityAuthentication StrengthMulti-Factor AuthenticationAuthentication DelegationExperienceDisjoint Sign OnGlobal Sign OnReduced Sign OnSingle Sign OnTo Achieve SSOCentral IssuerCredential ForwardingProtocol TransitionSingle CredentialMultiple CredentialsSingle SourceMultiple SourcesDSOGSORSOSSOAuthorizationAbstractionAuthorization hard coded into the appAbstract authorization away from the appCoarse-GrainedSimilar to locking your front doorWorks well at the Network and Operating System layersFine-GrainedRole-BasedDefine tasks based on your job and group them togetherAttribute-BasedApplication owns the decision based on claims about youPolicy-BasedDecision made centrally by the enterpriseAuditingMany PlacesNeeds to happen at every layerNetwork > VPN, SSL VPN, Access GatewayOS > Servers and clientsApplication > App-specific logs / web server logsResources > VariousMany SystemsAt the decision makerAt the applicationAt the entitlement sourceDecentralizationCollect logs from various systemsNormalize the dataAnalyze data / Generate reportsDrill down onto the 4AsThis is a quick overview slide that will be discussed in more detail. It's being provided for your reference.
4single view requests approvals Administration Build an accurate view of the identitysingle viewrequestsThe #1 goal of the administration pillar is to establish that “single view” of an identityThere are many solutions to this when dealing with on-premise identities:Automated Provisioning and De- provisioningSynchronizationManual AdministrationSelf-ServiceEntitlement managementManage business identity rules at the enterprise-levelUse a central identity management system as the request and approval brokerEnsure that your business processes can to the request and approval workflowsapprovalsAdministration is identity management – it can be manual, automated or some combination thereof.For coarse-grained access, assign application owners as approversFor fine-grained access, leverage the RBAC/ABAC/PBAC system in place
5experience security Authentication How much assurance is “enough”? Disjoint Sign OnMultiple credentialsMultiple authenticatorsGlobal Sign OnSingle set of credentialsReduced Sign OnSingle or Multiple credentialsSingle Sign OnCentral token issuerCredential forwardingProtocol transitionAuthentication StrengthDirectory bindsChallenge / ResponseAsymmetric CryptographyMulti-Factor AuthenticationAssurance levelsCostAuthentication DelegationAuthentication is the strength of the identityLDAP 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 wireKerberos 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.
6role-based abstraction attribute-based coarse-grained policy-based Authorizationrole-basedMake the best decision possibleabstractionBased on your job functionDefine tasks and group them togetherAuthorization hard-coded into the appExpensive and SlowAbstract authorization away from the appModularized operationsFlexibilityattribute-basedBased on something about youApplication owns the decision - ties attributes to operationsClaims-based accesscoarse-grainedOld way: embedded into the applicationAzMan (Authorization Manager): good try, but failed theClaims-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 XactmlNeed to understand how long it really takes to implement a policy-based access control solution.policy-basedSimilar to locking your front doorWorks well at the Network and Operating System layersExternalize the authorization decisionFits nicely into a SOA-based approachCentralized
7many places many systems Auditing Who did what, when, and how did they get access to it?many placesmany systemsAuditing needs to be comprehensive and occur at every layer in the access control modelNetworkVPN, SSL VPN, Access GatewayOperating SystemServers and potentially clientsApplicationApp-specific logs and web server logsResourcesAt the decision makerWhat was the decision and how was it made?At the applicationWhat did the identity do?At the entitlement sourceHow long did the identity have this attribute?AuditingEarly use: event logsCompliance has been driving the need for auditingTalk 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.
8many things decentralization Auditing Who did what, when, and how did they get access to it?many thingsdecentralizationAbility to illustrate who approved:A new or deleted identityAddition or subtraction of entitlements from an identityWho, 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 processesAbility to show auditors information surrounding an identities overall lifecycleAbility to create and provide reports on the aboveCollect logs from various systemsNormalize the dataAnalyze data / Generate reportsEmphasize 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.
9What is Microsoft Doing About My Identity Crisis? 15POINTINSPECTIONThe process begins with a 15-point identity inspectionThis is not a product. This is a solution that is focused on specific identity issues.
10Implementation Roadmap Provide customers with an roadmap based on customer goals and technology capabilitiesGives an end-state vision with incremental successLeverage Offerings:Enterprise Identity ManagementEnterprise Federated IdentitySome work may require a custom Services engagementFill in the gap over time with new offerings
11Services Offering: Security, Identity & Access Management (SIAM) DatacenterDesktopCloudProductivityMalware ProtectionRemote AccessData ProtectionIdentity ManagementFederated IdentityPublic Key InfrastructureNetwork ProtectionMail Protection and FilteringDocument Library Protection and FilteringRights ManagementSecure Remote AccessWeb ProtectionMail Protection GatewaySIAMSecured byThe implementation road map is just one of several offerings available from Microsoft Consulting Services.Microsoft is a product companyMCS is the solution organization within MicrosoftSIAM is a solution offering. It's not tied to any specific products
13Case Study in Washington State Identity ProviderResource ProviderPerson TableRetirement SystemsFederation ServerTrustFederation ServerPublicAuthenticationTrustFederation ServerHRMSRedirectDe-provisioningBrowseBrowseTrustIdentity ProvisioningPUBLICKEY POINTS 1. The left illustrates federated identity2. The right represents identity lifecycle/management3. Point out identity's relationship and extension beyond the directory (HRMS, Person Tables, Public Data)Web ApplicationEnterpriseActive DirectoryRedirectBrowseConstituent Data
14General Requirements - Authentication Active Directory used for authenticationCan authenticate users in the same forest as the AD FS serversCan authenticate users in trusted forests, but there must be a forest-level two-way trust in placeNon-Microsoft Identity Providers can be usedOnly Identity Providers that Microsoft has published a federation step-by-step guide forPartner agreements and paperwork must be in place prior to deployment of the solutionHome Realm Discovery page will not be customized as part of this engagementUser authentication over the InternetForms-based authentication onlyCertificate-based authentication can be used, but configuring it is outside the scope of this engagementCustomer can configure certificate authentication post-engagement if they wish
15General Requirements - Certificates Customer must supply SSL certificates for the federation serviceEach 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 certEach server must have a public/private key pairEach server is not required to use the same certificate, but they can if the issuer allows itCan purchase the necessary certificates from a third party issuing authorityMay need to purchase multiple certificates, depending on the issuer’s policiesWildcard or SAN certificates can be used, but are not necessaryCan issue the certificates from the customer’s Certificate AuthorityThe issuing CA must be trusted by all clients logging on to the federation serviceIdeal if your clients are all “managed clients”Not ideal if users are connecting over the internet with non-corporate computersHybrid Approach PossibleUse internally-issued certificates for the internal federation serversPurchase trusted certificates for Proxy federation serversThis slide outlines the certificate requirements for the solution. We need to ensure that the customer can meet these requirements.
16Solution Requirements for Federation Which Scenarios Apply?Internal employee accessAllow employees to achieve SSO to federated applications when on the networkAllow employees to achieve SSO to federated applications when working remotelyInternal organization may be a large, complex multi-forest infrastructure, looking to simplify access without trustsSharing applications with another organizationAllow partners to use their own accounts for accessing SharePoint 2007Allow partners to use their own accounts for accessing data protected with Active Directory Rights Management ServicesIncrease security by leveraging partner’s de-provisioning processAccess applications hosted by another organizationUse domain credentials for SSO and access to Office 365 applicationsUse domain credentials for SSO and access to partner-hosted applications
17Application Requirements for Federation Applications must be claims-aware.Net applications must use Windows Identity FoundationNon-Microsoft applications must use SAML 2.0 or WS-Federation protocolsCustomer will configure relying party trusts outside of this engagementExcept for Office 365, SharePoint 2007, or AD RMS relying partiesMicrosoft will not modify existing applications to make them claims-aware
18Requirements for Identity Synchronization Identity repositories must be identified and classified by integrity levelIdentity attributes must be identified and matched to authoritative repositoriesThis becomes the Metaverse or MetadirectorySecurity and distribution groups must be classified by security levelUser provisioning must be mapped outWhat systems are used during the entry and exit processes?What approvals are necessary for each system?Certificate management requirements must be defined