Alex Thissen | Achmea Designing and implementing a claims-based architecture Alex Thissen | Achmea Claim typeValue Alex Thissen Architect Microsoft CC

About me: Alex Thissen –Architect with a focus on Microsoft technologies and products Security Competencies and learning –Works at insurance company Achmea –Trainer/coach in software development –Most Valuable Professional for Visual C# –Regional Director for The Netherlands

About The Netherlands

The real Netherlands

Agenda Overview of claims-based security Design and architecture Claims-based security at Achmea Lessons learned Questions and answers

OVERVIEW OF CLAIMS-BASED SECURITY Getting into the basics

Corporate domain The need for claims based security Partner domain Internet Security from OS or platform Managed users Unmanaged users Potentially other platform

Leverage existing identities Users already have identities Reputation of provider Capabilities Web identities Corporate identities Issued identities Application identities Identity Provider Security Token Service 3 3 Identities

Claims, issuers, subjects and tokens Claim is attribute of identity Security token holds claimsets Cryptographically signed –Optionally encrypted Token Claimset Claims Issuer Subject

Tokens and claims Gordon wL6Xi5Z5uXQnSu40mRbkpljc5uKvf02HyASCo8uceNk= Token Signature Example Claims NameGroupOlder than 18 Claim 1 Claim 2... Claim n Claim 3 Indicates who created this token and guards against changes

Standards to make it all work Communication WS-Trust WS-Security WS-Secure Conversation WS-SecurePolicy Federation WS-Federation Passive requestor profile Active requestor profile Claims SAML XACML

Elements of claims-based architecture Identity Provider –Identity store –Security Token Service Relying Party (RP) –Application using claims Subject –User –Entity with identity Security token Trust Domain Identity Provider STS Identities 4 4 RP 3 3 Account or attribute store

Federation and trust Federation as an alternative when identity centralization is not an option Trust Domain 1Trust Domain 2 STS 3 3 User

Benefits of identity federation Allows claims-based security Reduce IT pain and risk related to provisioning and de-provisioning users Extend trust to users across domain, corporate and Internet boundaries Support Single Sign-On (SSO) Applications can ask for exactly claims they need

DESIGN AND ARCHITECTURE A shift in architecture

Design of a claims model Context-based profile Main profile Credentials Identifier Application attributes E.g. roles in application, identity bound information relevant to application Common attributes E.g. address, user name, company name Username/password X509 certificate Kerberos ticket Other security token Unique identifier of identity Per domain uniqueness E.g. samAccountName, SSN, certificate ID Source: Microsoft Architecture Journal #16

Separation of concerns Provisioning of identities and claims issuance by authoritative source Different issuers –Main profile and identifier: IP-STS –Context based profile: Resource-STS (aka Federation-STS)

Federation pattern primitives Transformation Augmentation Can be combined

Usage Customizations STS Provisioning ILM Development Single authentication model in apps Leverage services and support from platform Operation Partly redundant infrastructure Environment separation Security Security standards No custom security implementation Using security products *ilities

Migrating to claims Security model Claims-based access control Less emphasis on traditional role-based security Authentication Brokered authentication Generate claims and token Authorization Use claims instead of other data No longer dependent on authentication mechanism

Shift in architecture Decoupling –Security model from authentication type –Authentication implementation from application code Centralization of identities Federation with other parties (trust) Authentication logic Separate identity and attribute stores

Authentication logic Shift in architecture Decoupling –Security model from mode of authentication –Security implementation from application code Centralization of identities Federation with other parties (trust) Centralized identity store Authentication logic User Multiple web applications

Identity and access management Unified Access Gateway Identity Manager 2010 (ILM) Window Identity Foundation Windows Communication Foundation ASP.NET 3.5 WIF integration Microsoft platform, products and frameworks Infrastructure Software Domain Services Lightweight Directory Services Federation Server 2.0 Certificate Services

Implementing claims-based security 1.Acquire or build issuer 2.Configure application to trust issuer 3.Configure issuer to know about application 4.Add logic to your application to support claims

IDENTITY & ACCESS MANAGEMENT AT ACHMEA A real-world example

Achmea target architecture Based on Achmea IT vision –“Inleven, vernieuwen, waarmaken” Rationalize existing application landscape Leverage products OOB Minimize custom implementations

Divisions and labels Adopt to modern internet usage Reduced effort on creating and provisioning customer accounts Achmea IT Centralizing and providing generic infrastructure Deliver more services at lower cost and higher SLA Business case

Generic Internet-street Achmea Centralizing services for hosting and securing internet portals Reduce costs by standardizing platform SharePoint 2010 for building Web Portals Photo by Paul KellerPaul Keller

Customer Domain Customers Identity and access management SharePoint 2010 Application farm Attributes ADFS 2.0 Resource- STS AD Lightweight Directory Services DigiD IP-STS Identity Attribute Healthcare Division ClaimValue SSN ClaimValue Cn Identity Role Insured ClaimValue SSN ClaimValue Cn Identity Role Insured

Employees Customer Domain Employees Domain Customers Identity and access management ADFS IP-STS ADFS IP-STS AD Domain Services Attributes ADFS 2.0 Resource- STS AD Lightweight Directory Services DigiD IP-STS Identity Attribute Healthcare Claim augmentation and transformation Other Divisions InternalIntermediaries Access Control Service

Windows Azure Access Control Service Relying Party Web Relying Party Web Access Control Access Control Google Yahoo! Windows Live Windows Live FaceBook Browser Enterprise Identity Provider 3 3

SOFTER SIDE OF CLAIMS-BASED SECURITY Lessons learned from a changing security architecture

IT Environment Governance on identities and claims –Meta model for claims Availability of technology –E.g. currently government IP-STS DigiD does not have a STS Specialized team for Identity & Access Management is advised

Human dynamics Encourage to move towards target architecture Negotiations − Active vs. passive authentication − “Everything is an attribute”

Interaction challenges Design of attributes for claims Authorization model What makes a good claim? Volatile, main or context profile?

New technologies Relative new technologies –Frameworks –Products Non-trivial standards Distributed teams

WRAPPING UP Almost there

Lessons learned Achieving your goals in more than one step Taskforce can be very effective –Right people together with a single mission Multiple parties means multiple strategies, agendas and plannings External contractors may have a different view on target (software) architecture

Summary Claims-based security as a new paradigm Needs a different security architecture Trust and federation are essential Start transitioning from role based to claims based security architecture!

Q&A and discussion Go ahead and ask your questions now!

Resources Ebook “A guide to Claims-based Identity and Access Control”Ebook “A guide to Claims-based Identity and Access Control” Microsoft Architecture Journal # 16Microsoft Architecture Journal OASIS Standards Microsoft resources: –WIFWIF –Active Directory ServerActive Directory Server

Alex Thissen | Achmea Thank blog.alexthissen.nl Alex Thissen |