7. Your Presenters for Today Maarten @maartenballiauw / about.me/maarten.balliauw Co-founder of AZUG MVP: Windows Azure Blogs at http://blog.maartenballiauw.be Paul @ploonen / paul@winsec.be Co-founder of winsec.be MVP: Microsoft Forefront Identity Manager MCM Directory Current hobby: Architect@Avanade Blog @ http://be-id.blogspot.com
8. Agenda Presenting the problem (a.k.a. “The Scenario”) How federation saves the day How ADFS solves federation How to connect an app to ADFS How Windows Azure adds extra sauce to federation Q&A
12. Federation benefits Benefits of SSO reduce administrative overhead reduce security vulnerabilities as a result of lost or stolen passwords improve user productivity Intra-Enterprise: provide SSO for all your web sites and applications Inter-Enterprise: provide SSO experiences for your users to access apps in other organizations provide SSO experience for users from external organizations to access your apps Easily externalize authentication & authorization Rich claims rules processing engine Management & Configuration Tools
13. What is AD FS 2.0? Other Claims Providers AD FS 2.0 provides access and single sign-on for on-premises and cloud-based applications in the enterprise, across organizations, and on the Web CA IBM SUN AD FS 2.0 Major Components Federation Server Federation Server Proxy WIF Attribute Stores Claims Engine Website Management Snap-in Other STS Web Service Active Directory Windows Server 2008 SP2, 2008 R2 MS SQL Relying Parties Browser Apps WIF Windows Internal DB .NET 3.5 SP1 IIS 7 Smart Clients Web Services
14. Why consider AD FS 2.0? Building a production-ready STS is hard. The Visual Studio STS templates are just starters for trivial dev scenarios. Lots of configuration to manage, UI's to present in real world STS!
15. Typical Traffic Flow Identity Provider Relying Party Federation Trust Active Directory Account Resource Federation Server Federation Server Web Server Internal Client
16. Scenario 1 – Intra Organization Claims-aware app ADFS STS Active Directory User App trusts STS Browse app Not authenticated Redirected to STS Authenticate Return Security Token Query for user attributes Send Token ST ST Return pageand cookie
17. Scenario 2 – Inter Organization ActiveDirectory Your ADFS STS Partner ADFS STS & IP YourClaims-aware app Partner user Browse app Not authenticated Redirect to your STS Home realm discovery Redirected to partner STS requesting ST for partner user Authenticate Return ST for consumption by your STS Redirected to your STS ST ST ST ST Process token Return new ST Send Token Return pageand cookie
18. Installing AD FS v2 Requires Windows Server 2008 / 2008 R2 Requires IIS 7, .NET 3.5 SP1, WIF See deployment guide for required hot fixes and updates Issue and install server certificates for HTTPS Think about implications for partner organisation Cross certification when few partners, otherwise, buy required certs Download and install ADFS 2.0 Simple Wizard New / farm member / Proxy – SSL cert – Names
22. AD FS 2.0 deployment options Single server configuration AD FS 2.0 server farm and load-balancer AD FS 2.0 proxy server (offsite users) Active Directory AD FS 2.0 Server Proxy AD FS 2.0 Server AD FS 2.0 Server AD FS 2.0 Server Proxy External user Internal user DMZ Enterprise
23. Configuring your AD FS Server Or: %ProgramFiles%ctive Directory Federation Services 2.0sConfigWizard.exe Manually: FsConfig.exe { StandAlone | CreateSQLFarm | JoinFarm | JoinSQLFarm | GenerateSQLScripts} [deployment specific parameters]
28. Claim Rules Rule templates simplify the creation of rules Examples of rules are: Permit / deny user based on incoming claim value Transform the incoming claim value Pass through / filter an incoming claim Multiple claim rules can be specified and are processed in top to bottom order Results from previously processed claims can be used as the input for subsequent rules
30. Creating Rules Condition Issuance Statement A claim rule consists of two parts, condition and issuance statement
31. Custom Claims Capabilities of custom rules include Sending claims from a SQL attribute store Sending claims from an LDAP attribute store using a custom LDAP filter Sending claims from a custom attribute store Sending claims only when 2 or more incoming claims are met Sending claims only when an incoming claim matches a complex value Sending claims with complex changes to an incoming claim value Creating claims for use in later rules
35. Windows Identity Foundation Your one and only partner for .NET identity development Adds claims-based authentication to your application in no time My advise: forget custom user stores And if you need them: WIF-ify (?) them
37. Where things get cloudy... Windows Azure AppFabricAccess Control Service ACS
38. Windows Azure AppFabric ACS An STS in the cloud Pluggable with identity providers Windows Live ID Facebook Google Yahoo! Any ADFS or better: any WS-federation passive endpoint Any OAuth2 provider
40. Let’s step back... No, we’re not the US Federation across organizations does not happen often today So why would I use ACS anyway? Dev, test, accept, prod are different RP’s! 2 apps with all these environments is 8 RP’s! Imagine 10 apps... Or a hundred...
41. ACS advantages A scalable STS With one or more identity providers With one or more relying parties With one or more rule groups Integrates with WIF Integrates with ADFS Instant win!
42. ACS Identity Providers Your Application ACS SAML SWT Browser-based WS-Federation ADFS2 . WS-Federation Rich Client SAML WS-Trust ADFS2 . WS-Trust Server 2 Server SWT OAuth WRAP/2.0 Service Identities
47. Conclusion It is possible to do SSO over security boundaries It is possible to integrate multiple apps with multiple identity providers ADFS and ACS form a nice couple Standards based solution
48. Some Resources AD FS v2 on TechNet and MSDN AD FS v2 content on TechNet Wiki Claims-Based Identity Blog Windows Azure AppFabric Access Control Service WIF and ACS Content Map on Technet Wiki Vittorio’s Blog http://identityserver.codeplex.com
Real world STS's need to manage multiple relying parties, each with multiple claim issuance and authorization rules. Delegation authorization for users of the RP require even further configuration. Federated scenarios add requirement for trusting other STS's.Access to Identity Providers and Attribute Stores, rules for querying
Here there’s a list of cloud scenarios we consider of interest in term of how identity is handled.<click> our baseline is the classic on premises scenario.<click> you have a data center, <click> a population of internal users and <click> some authentication infrastructure, such as Active Directory, maintaining their accounts.<click> applications targeting such environment will follow the current intranet practices.<click> We will then introduce Windows Azure in the picture and observe how things change when the application moves to the cloud; we'll consider this both from the architecture and products usage perspectives.<click> Then we'll move to consider what happens when the application is exposed to multiple business partners, and the implications on authentication and relationships management.<click> However business partners represent an important but tiny fraction of all the possible population <click> you an cater to if you target the internet users.<click> live id, Google, Facebook and yahoo! have hundreds of millions of users; the authentication requirements in those conditions are completely different than the business case, although as we will see the solutions may end up being surprisingly similar.<click> Finally, the mobile scenario is of great importance and again apparently a completely different problem space. Using claims-based identity makes it very easy to progressively accommodate all those different scenarios.
The ACS would deserve multiple sessions on its own right to be properly covered, here I'm just giving you a quick sampler.What we have seen so far is just a small part of its surface. The schema here shows the ws-federation subsystem, what is normally used for browser-based, session-oriented application types. We've been playing only with ADFS IP types, but in fact <click> there are many out of the box popular IPs you can use right away with your application sticking to the same protocol <click> and a browser<click>.ACS can also do WS-Trust, a high-security protocol for SOAP web services, accepting identities from ADFS2 ws-trust endpoints or bare credentials registered in ACS for management purposes.<click> the same sources can be used within OAuth2.0 calls. OAuth is the current state of the art for securing REST calls: it is still in draft state, hence expect changes, but you can already experiment with it.<click> Both protocols can be used for rich client application types and in general <click> server 2 server interactions.Not shown here there are the management endpoints, the other portion of ACS' development surface, which can be used instead or alongside the portal for managing the namespace.