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 ;-)