Download - Single sign on with TYPO3
Single Sign On with TYPO3 –
Case StudiesThomas Schikarski
Irene HöppnerLea Schikarski
Irene Höppner
Specialized in TYPO3 since 9 yearsCo-author of “TYPO3-Profihandbuch” and trainer of two TYPO3 DVD video trainingsSenior developer with in2code GmbHin2code GmbH (http://www.in2code.de/) Formerly member of A.BE.ZET GmbH (which is now “elementare teilchen GmbH”)
Thomas Schikarski
Experience in IT infrastructure and IT service management, incl. applications of cryptographic technologyExperience with the SSO part of several TYPO3 projectsPart-time freelancer
Lea Schikarski
CrawlingRunningSwingingDrawingExpressing herself with signsParticipation in: TYPO3camp Munich 2011, T3DD12, FLOW3 Experience 2012 (F3X), TYPO3camp Munich 2012, T3CON12DE
Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary
Why SSO?
Users don‘t have to memorize / enter many passwordsUser management simplified (e.g. disabling access on all systems)Linked information (e.g. storing favorites of one system in another)
Levels of „Single Sign-On“
Level 1: sharing credentials– Username / password valid on > 1 systems– Synchronized password changes
Level 2: + “single sign-on”– Logging on (and off) only once for all
systems– Log on/off screens may be present in 1..all
systems
Level 3: + “seamless”– Log on takes place on system level
The Simple Case
Log on / -off functionality is centralized on one systemA valid session on one system is accepted by the other systemThe authenticating system may be separate or part of one of the application systems
or
SSO with TYPO3 CMS
Protect your content as usualUse “auth services” to add authentication methodsYou always need a record in be_users/fe_users (but auth service can auto-import users)
Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary
Case 1: Seamless SSO in a Windows Domain
Customer: Call center with ~200 employeesTYPO3: Intranet solution (knowledge base to be used by call agents)User-specific data was stored (e.g. news alerts, list of unread news)Logon-System: Windows Active Directory
Case 1: Special challenges
Customer required to use a Windows machine Apache on WindowsSeamless integration using mod_auth_sspiRetrieving user information using LDAP extensionsLesson learned: Internet Explorer sometimes does not send POST data, when expectedAdditional users outside Active Directory needed alternative authorization scheme (IP range)
Case 2: Authentication against SAP
Intra- and Extranet portal for company-specific training offersTYPO3: Content elements and Plugins for access to trainings stored in SAPUsers authenticate against SAP (only interns)SOAP webservices were provided within SAP– Login / Logoff / Session validity / user
information– Personalized content (e.g. favorite
trainings)
Case 2: Special challenges
SAP provides Session-TokenSession-Token needs to be used as a Cookie in two ways– Server to Server access (SOAP)– Linked content (Browser)
Domains- and Sub-Domains have to be chosen carefully to allow Cookie-transfer
Case 3: OpenSSO
Remark: “OpenSSO” now has a fork “OpenAM”Health insurance company hosts a number of different systems that allow user access integration project including internal / external TYPO3 sitesInternal and external usersLogin / Logoff pages within TYPO3-FE requiredRESTful services (Login, Check valid session, Logoff)
Case 3: Special challenges
Login and logoff forms need to influence– TYPO3 session– OpenSSO session
Character encoding of session token was interpreted differently on OpenSSO and on TYPO3 side (JAVA vs. PHP)
Case 4: Shibboleth
University hosting > 200 TYPO3 sitesBE user management needed improvementShibboleth is a federated identity solution– Allows to use > 1 identity provider–Well suited for educational sector, with
high level of co-operations– Apache module and server component– Cookies and redirects; SAML messages
Case 4: Shibboleth (cont’d)
Complex configurations to be matched:– Shibboleth identity provider– Shibboleth service provider component– Apache module $_SERVER– extConf
First application: BE Login of editors– Autoimport of users in disabled state
Complex, versatile mapping of attributes
Case 4: Special Challenges
Very versatile mapping of Shibboleth-attributes to TYPO3 user properties (fields, groups) with TypoScript-style config fileHandling session across load-balancing clusterVery complex project structure (Identity management, hosting of identity provider, hosting of web servers, TYPO3 experts)
Case 5: TYPO3 as Authentication Master
TYPO3 used for technical customer relation mgmt. (providing product information)User management within TYPO3 (e.g. se_feuser_register)Ticketing system (Atlassian JIRA) to authenticate against TYPO3 usersProviding SOAP web services to external applicationsManagement of applications (SOAP-credentials etc.)
Case 5: Special Challenges
Providing lean web services, but having loaded all needed TYPO3 classesSecurity!
Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary
Infrastructure
Cookies & DomainsTo use a common cookie, all systems must be found under the same second level domain
Server typically has to meet special requirementsIn many cases special auth modules are needed
Early clarification with customer / infrastructure experts necessary!
Authorization and User Specific Data
“Authentication” is not “authorization”
Which system “decides” about authorization? Which information is decisive?Auto-import of users into TYPO3?Which system holds other user specific data?
Scope of Login
User experience and expectation– Scope of Logon? What systems know
about me?
Logout scenariosTimeout synchronization vs. server load
Complex Project Teams
Need to harmonize these people:– Project owner (knows content)– Identity management (knows users)– Server hosting (knows server systems)– Network specialists (know network
structure and firewalls)
Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary
Summary
No two SSO projects are the sameImplementing / integrating SSO requires to coordinate a large number of participantsTypically, main stake holders are unaware of the complexity
Slides: http://de.slideshare.net/tschikarski
Thank you for your attention!
Excurse: Authentication “channels”
Browser (Rendering, e.g.
HTML)
Client Webserver
Browser (Protocols, e.g.
HTTP)
Network stack of OS
Application (e.g. TYPO3)
Webserver(e.g. Apache)
Network stack of OS
HTML Login Form
htaccess
IP-Address
More Things to Take Care of (cont’d)
Difficult debugging– No FE/BE output possible in many cases– Redirects – you might want to die()– No success without devlog extension! ;-)
Build your tool box! – http traffic– Test, what you get from the others!
References
mod_auth_sspi: http://sourceforge.net/projects/mod-auth-sspi/
LDAP extensions by Daniel Thomas:http://typo3.org/extensions/repository/view/ldap_auth/ http://typo3.org/extensions/repository/view/ldap_server/
Atlassian JIRA: http://www.atlassian.com/software/jira/overview
OpenSSO: http://www.oracle.com/technetwork/testcontent/opensso-091890.html
OpenAM: http://www.forgerock.com/openam.html
Shibboleth: http://shibboleth.net/
Credits
in2code GmbHelementare teilchen GmbH (formerly known as „A.BE.ZET GmbH“)Rene Fritz, Francois Suter for developing devlog ;-)