410 likes | 710 Views
ASR Final Project February 7 th , 2007. Federated Identity with Ping Federate. -------------------------------------------- Eunice Mondésir Pierre Weill-Tessier --------------------------------------------. Project Supervisor: M. Maknavicius-Laurent ASR Coordinator: G. Bernard. Agenda.
E N D
ASR Final Project February 7th, 2007 Federated Identity withPing Federate -------------------------------------------- Eunice Mondésir Pierre Weill-Tessier -------------------------------------------- Project Supervisor: M. Maknavicius-Laurent ASR Coordinator: G. Bernard
Agenda • Introduction • Federated Identity concepts • Presentation of Ping Federate server • Platform implementation • Demonstrations • Conclusion
Federated Identity concepts • Why Federated Identity? • What is Federated Identity? • Participants of Circle of Trust • Single Sign On and Single Log Out • SAML langage
Federated Identity Concepts 1. Why federated identity?
Federated Identity Concepts 1. Why federated identity? • Multiple authentication parameters • Heterogeneous authentification and access control methods • No control on personal information’s exhibition • Need for easier and faster acces to services
Federated Identity Concepts 2. What is federated identity? • Set of agreements, standards and technologies • Trust relationships between organizations • Integrity and privacy perserved • Independance of organizations
Federated Identity Concepts 3. Circle of Trust (CoT) participants • Service Provider (SP): • Provides one or more services within a federation • Access control policy • Identity Provider (IdP): • Creates, maintains, manages identity information • user must authenticate at an IdP recognized by a SP
Federated Identity Concepts 3. Circle of Trust (CoT) participants CoT • Circle of trust: • Federation of IdP and SP • Business relationships • Operational agreements • Secured communication channels • Seamless environment SP SP SP IdP SP SP SP
Federated Identity Concepts 4.SSO and SLO • Liberty alliance • Single Sign On (SSO): • Sign on once at a site (single account) • Seamless signed-on for other sites • No extra authentication • SP both within and across circles of trusts • Single Log Out (SLO): • Synchronized session logout • All sessions authenticated by an IdP closed
Federated Identity Concepts 5. SAML (Security Assertion Markup Langage) • XML standard developped by OASIS • Exchanging authentication & authorization data between security domains (IdP and SP) • SSO solution beyond the intranet • Exchange of assertions between IdP and SP
Presentation of Ping Federate server • How does Ping Federate work ? • Communication tools of Ping Federate
Presentation of Ping Federate server 1. How does Ping Federate work ? • Server that passes identities between CoTs • Distinction between two roles: IdP and SP • Both roles can be combined • Ping Federate does not interfere with local usage of the application
Application or IdM X programming language PF Token SAML adapter agent Presentation of Ping Federate server 2. Communication tools in PF server • different environments: how communicate? • Ping Federate provides Integration Toolkits**
Platform Implementation • Needs • LDAP • Postfix • Tomcat • Ping Federate server
Platform Implementation 1. Needs • Applications often interacts with a database for authentication • Ping Federate server asks for parameters of a mail server to send notification mail • Ping Federate’s sample application runs on Tomcat Application Server
Platform Implementation 2. LDAP • Why this protocol ? • LDAP adapter proposed by PF • Authentication to IdPs via pop-up window • Our configuration: • Server OpenLDAP • Client LDAPBrowser to check our entries • Simple tree: root + inetOrgPerson class instances
Platform Implementation 2. LDAP • Example of LDAP Tree: dn: o=INT,c=FR dn: cn=Eunice, o=INT, c=FR dn: cn=Pierre, o=INT, c=FR • Attributes we used: • cn, sn • mail, userPassword • title
Platform Implementation 3. Postfix • Why ? • mail server working on Linux O.S • “Lighter” configuration than Sendmail • No database associated : only one user ! • liberty@cubitus.int-evry.fr • IdpAdmin@cubitus.int-evry.fr is a “fake” address used for the notification only. • IMAP server as a MDA
Platform Implementation 4. Tomcat • Why ? • Required applications server to test the samples • Multi-technologies support server (jsp, html) • Identification tools: • Double authentication based on Role and Login • Default configuration • LDAP-using configuration JNDI
Platform Implementation 4. Tomcat • Key configuration files • server.xml: defines the database connection • web.xml: defines the security constraint
Platform Implementation 5. Ping Federate • Standalone web administration • https://cubitus.int-evry.fr:9999/pingfederate/app • Support of multi-account administration • Modifiable role selection (IdP, SP or both) • Ease of management • Server configuration • Partner configuration
Platform Implementation 5. Ping Federate • Server settings • Local settings • Base URL: where reaching the server ? • Federation Info: choice of technologies • Entity ID / realm: outside Ping Federate alias • IdP/SP events: systematic redirections
Platform Implementation 5. Ping Federate • Server settings • Local settings • IdP/SP adapters management • Data Store management • Metadata export
Platform Implementation 5. Ping Federate • Partner settings’ connections • IdP connections = we are SP • SP connections = we are IdP • SP affiliations = 2+ partners’ Federation According to partners’ configuration = Each CoT defines its policy independently
Test Platform implementation • Before Ping Federate servers • Simplification • Ping Federate servers setting-up • IdP initiated SSO with ITAM • SP initiated SSO with ITAM • SP initiated SSO with LDAP adapter
ITAM CoT IdM INT CoT INT Services S1 S1 S2 S2 S3 IdM S3 ITAM Services 1. Before Ping Federate servers Connection to INT services within INT
ITAM CoT IdM INT CoT INT Services S1 S1 S2 S2 S3 IdM S3 ITAM Services 1. Before Ping Federate servers Connection to INT services from outside INT
ITAM CoT IdM INT CoT INT Services S1 S1 S2 S2 S3 IdM S3 ITAM Services 1. Before Ping Federate servers Connection to ITAM serviceswithin INT or from outside INT not possible
IdM S1 S1 ITAM CoT IdM IdM INT CoT S1 S2 S3 INT Services S1 S2 S3 IdM ITAM Services 2. Simplification • All aplications hosted by tomcat server • Authentcation files serving as database
IdM S1 S1 IdM INT CoT IdP & SP ITAM CoT cubitus IdP oberon SP titania 3. PF servers setting up • For INT CoT: only one PF server (IdP and SP server) • For ITAM CoT: two PF servers, one IdP and one SP
IdM S1 S1 SSO SAML 2.0 IdM INT CoT IdP ITAM CoT Sarah IdP oberon SP titania cubitus 4. IdP initiated SSO with ITAM Sarah connected to S1 without having passed by ITAM IdM
IdM S1 S1 SAML 2.0 IdM INT CoT IdP ITAM CoT SAML 2.0 Bob IdP oberon SSO SP titania cubitus 5. SP initiated SSO with ITAM
IdM S1 S1 SAML 2.0 IdM INT CoT IdP ITAM CoT SAML 2.0 Sam IdP oberon SSO SP LDAP titania cubitus 6. SP initiated SSO with LDAP adapter LDAP adapter standard adapter INT IdP interaction with LDAP directory via a pop-up window
Conclusion • What remains to do ? • Adapt INTest with Ping Federate (Token) • Test Multi-partners federation • Perform tests on security and privacy • Other solutions ? • Microsoft CardSpace (.NET) • WS-Federation • Servers (Sun One Identity Server, IBM Tivoli, Microsoft ADFS…)
Thanks for your attention Questions ?