Single sign on with TYPO3
Upcoming SlideShare
Loading in...5

Single sign on with TYPO3



Held at t3con12de (TYPO3 conference 2012, Stuttgart)

Held at t3con12de (TYPO3 conference 2012, Stuttgart)



Total Views
Views on SlideShare
Embed Views



1 Embed 1 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Single sign on with TYPO3 Single sign on with TYPO3 Presentation Transcript

  • Single Sign On with TYPO3 – Case Studies Thomas Schikarski Irene Höppner Lea Schikarski
  • Irene HöppnerSpecialized in TYPO3 since 9 yearsCo-author of “TYPO3-Profihandbuch” andtrainer of two TYPO3 DVD video trainingsSenior developer with in2code GmbHin2code GmbH ( member of A.BE.ZET GmbH(which is now “elementare teilchen GmbH”)
  • Thomas SchikarskiExperience in IT infrastructure and IT servicemanagement, incl. applications ofcryptographic technologyExperience with the SSO part of several TYPO3projectsPart-time freelancer
  • Lea SchikarskiCrawlingRunningSwingingDrawingExpressing herself with signsParticipation in: TYPO3camp Munich 2011,T3DD12, FLOW3 Experience 2012 (F3X),TYPO3camp Munich 2012, T3CON12DE
  • OutlineMotivation and general aspects of SSOReal-world examples and lessons learnedMore things to take care ofSummary
  • Why SSO?Users don‘t have to memorize / enter manypasswordsUser management simplified(e.g. disabling access on all systems)Linked information(e.g. storing favorites of one system inanother)
  • Levels of „Single Sign-On“Level 1: sharing credentials– Username / password valid on > 1 systems– Synchronized password changesLevel 2: + “single sign-on”– Logging on (and off) only once for all systems– Log on/off screens may be present in 1..all systemsLevel 3: + “seamless”– Log on takes place on system level
  • The Simple CaseLog on / -off functionality is centralized onone systemA valid session on one system is accepted bythe other systemThe authenticating system may be separate orpart of one of the application systems
  • or
  • SSO with TYPO3 CMSProtect your content as usualUse “auth services” to add authenticationmethodsYou always need a record in be_users/fe_users(but auth service can auto-import users)
  • OutlineMotivation and general aspects of SSOReal-world examples and lessons learnedMore things to take care ofSummary
  • Case 1: Seamless SSO in a Windows DomainCustomer: Call center with ~200 employeesTYPO3: Intranet solution (knowledge base tobe 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 challengesCustomer required to use a Windows machine Apache on WindowsSeamless integration using mod_auth_sspiRetrieving user information using LDAP extensionsLesson learned: Internet Explorer sometimes doesnot send POST data, when expectedAdditional users outside Active Directory neededalternative authorization scheme (IP range)
  • Case 2: Authentication against SAPIntra- and Extranet portal for company-specific training offersTYPO3: Content elements and Plugins foraccess 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 challengesSAP provides Session-TokenSession-Token needs to be used as a Cookie intwo ways– Server to Server access (SOAP)– Linked content (Browser)Domains- and Sub-Domains have to be chosencarefully to allow Cookie-transfer
  • Case 3: OpenSSORemark: “OpenSSO” now has a fork “OpenAM”Health insurance company hosts a number ofdifferent 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 challengesLogin and logoff forms need to influence– TYPO3 session– OpenSSO sessionCharacter encoding of session token wasinterpreted differently on OpenSSO and onTYPO3 side (JAVA vs. PHP)
  • Case 4: ShibbolethUniversity 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– extConfFirst application: BE Login of editors– Autoimport of users in disabled stateComplex, versatile mapping of attributes
  • Case 4: Special ChallengesVery versatile mapping of Shibboleth-attributes to TYPO3 user properties (fields,groups) with TypoScript-style config fileHandling session across load-balancing clusterVery complex project structure (Identitymanagement, 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 users Providing SOAP web services to external applications Management of applications (SOAP-credentials etc.)
  • Case 5: Special ChallengesProviding lean web services, but having loadedall needed TYPO3 classesSecurity!
  • OutlineMotivation and general aspects of SSOReal-world examples and lessons learnedMore things to take care ofSummary
  • 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!
  • 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 LoginUser experience and expectation– Scope of Logon? What systems know about me?Logout scenariosTimeout synchronization vs. server load
  • Complex Project TeamsNeed to harmonize these people:– Project owner (knows content)– Identity management (knows users)– Server hosting (knows server systems)– Network specialists (know network structure and firewalls)
  • OutlineMotivation and general aspects of SSOReal-world examples and lessons learnedMore things to take care ofSummary
  • 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 complexitySlides:
  • Thank you for your attention!
  • 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
  • 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!
  • Referencesmod_auth_sspi: extensions by Daniel Thomas: JIRA:
  • Creditsin2code GmbHelementare teilchen GmbH(formerly known as „A.BE.ZET GmbH“)Rene Fritz, Francois Suter for developingdevlog ;-)