This document discusses single sign-on (SSO) with TYPO3 CMS and provides examples of real-world SSO implementations. It describes five case studies of SSO projects involving integration with Windows Active Directory, SAP, OpenSSO, Shibboleth, and using TYPO3 as the authentication master. The document outlines important considerations for SSO projects, such as infrastructure requirements, authorization vs. authentication, and coordinating complex project teams. No two SSO projects are alike and implementing SSO requires coordinating many participants to address technical and organizational challenges.

1. Single Sign On with TYPO3 –
Case Studies
Thomas Schikarski
Irene Höppner
Lea Schikarski

2. Irene Höppner
Specialized in TYPO3 since 9 years
Co-author of “TYPO3-Profihandbuch” and
trainer of two TYPO3 DVD video trainings
Senior developer with in2code GmbH
in2code GmbH (http://www.in2code.de/)
Formerly member of A.BE.ZET GmbH
(which is now “elementare teilchen GmbH”)

3. Thomas Schikarski
Experience in IT infrastructure and IT service
management, incl. applications of
cryptographic technology
Experience with the SSO part of several TYPO3
projects
Part-time freelancer

4. Lea Schikarski
Crawling
Running
Swinging
Drawing
Expressing herself with signs
Participation in: TYPO3camp Munich 2011,
T3DD12, FLOW3 Experience 2012 (F3X),
TYPO3camp Munich 2012, T3CON12DE

5. Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary

7. Why SSO?
Users don‘t have to memorize / enter many
passwords
User management simplified
(e.g. disabling access on all systems)
Linked information
(e.g. storing favorites of one system in
another)

8. 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

9. The Simple Case
Log on / -off functionality is centralized on
one system
A valid session on one system is accepted by
the other system
The authenticating system may be separate or
part of one of the application systems

10. or

11. SSO with TYPO3 CMS
Protect your content as usual
Use “auth services” to add authentication
methods
You always need a record in be_users/fe_users
(but auth service can auto-import users)

12. Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary

13. Case 1: Seamless SSO in a Windows
Domain
Customer: Call center with ~200 employees
TYPO3: 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

16. Case 1: Special challenges
Customer required to use a Windows machine 
Apache on Windows
Seamless integration using mod_auth_sspi
Retrieving user information using LDAP extensions
Lesson learned: Internet Explorer sometimes does
not send POST data, when expected
Additional users outside Active Directory needed
alternative authorization scheme (IP range)

17. Case 2: Authentication against SAP
Intra- and Extranet portal for company-
specific training offers
TYPO3: Content elements and Plugins for
access to trainings stored in SAP
Users authenticate against SAP (only interns)
SOAP webservices were provided within SAP
– Login / Logoff / Session validity / user information
– Personalized content (e.g. favorite trainings)

20. Case 2: Special challenges
SAP provides Session-Token
Session-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

21. 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 sites
Internal and external users
Login / Logoff pages within TYPO3-FE required
RESTful services (Login, Check valid session,
Logoff)

24. 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)

25. Case 4: Shibboleth
University hosting > 200 TYPO3 sites
BE user management needed improvement
Shibboleth 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

26. 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

29. Case 4: Special Challenges
Very versatile mapping of Shibboleth-
attributes to TYPO3 user properties (fields,
groups) with TypoScript-style config file
Handling session across load-balancing cluster
Very complex project structure (Identity
management, hosting of identity provider,
hosting of web servers, TYPO3 experts)

30. 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 users
Providing SOAP web services to external
applications
Management of applications (SOAP-credentials
etc.)

33. Case 5: Special Challenges
Providing lean web services, but having loaded
all needed TYPO3 classes
Security!

34. Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary

35. Infrastructure
Cookies & Domains
To use a common cookie, all systems must be found
under the same second level domain
Server typically has to meet special
requirements
In many cases special auth modules are needed
Early clarification with customer /
infrastructure experts necessary!

36. 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?

37. Scope of Login
User experience and expectation
– Scope of Logon? What systems know about me?
Logout scenarios
Timeout synchronization vs. server load

38. 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)

39. Outline
Motivation and general aspects of SSO
Real-world examples and lessons learned
More things to take care of
Summary

40. Summary
No two SSO projects are the same
Implementing / integrating SSO requires to
coordinate a large number of participants
Typically, main stake holders are unaware of
the complexity
Slides: http://de.slideshare.net/tschikarski

41. Thank you for your attention!

42. Excurse: Authentication “channels”
Browser Application
HTML Login Form
(Rendering, e.g. HTML) (e.g. TYPO3)
Browser Webserver
htaccess
(Protocols, e.g. HTTP) (e.g. Apache)
Network stack of OS IP-Address Network stack of OS
Client Webserver

43. 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!

44. 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/

45. Credits
in2code GmbH
elementare teilchen GmbH
(formerly known as „A.BE.ZET GmbH“)
Rene Fritz, Francois Suter for developing
devlog ;-)