Mapping Configuration File

Under Resources/Private/sample-config.txt you find a sample config file. It makes use of the Typoscript parser to achieve maximum flexibility. To better understand, what it does, let’s examine it’s structure.

tx_shibboleth {
    FE {
        // definitions for frontend authentication and authorization
    }
    BE {
        // definitions for backend authentication and authorization
    }
}

Explanations:

As you can see, there are two different sections for frontend and backend authentication and authorization. Both work identically. However, you might need to set different fields in the respective TYPO3 user table.

Let’s start with a backend example.

tx_shibboleth {
    BE {
        IDMapping {
            // Map Shibboleth ID to TYPO3 username
            shibID = TEXT
            shibID.field = eppn
            typo3Field = username
        }
        userControls {
            // Control, how the user is imported and logged in
            // 'allowUser' decides, if the user is accepted by TYPO3. Set to 0 or 1.
            allowUser = TEXT
            allowUser.value = 1
            createUserFieldsMapping {
                // Set additional fields, when the user is imported for the FIRST TIME
                email = TEXT
                email.field = REMOTE_USER

                admin = TEXT
                admin.value = 0
            }
            updateUserFieldsMapping {
                // Update the user with these field values at EVERY LOGIN
                admin = TEXT
                admin.value = 0
            }
        }
    }
}

Explanations:

Within IDMapping you have to tell TYPO3, where in the Shibboleth data it finds the username. Set shibID to the desired value by referencing the appropriate Shibboleth attribute (REMOTE_USER in our example). In standard TYPO3 installations typo3Field must be set to username. Take care to select a unique Shibboleth field.

Hint: Make sure your selection of the identifier field ist appropriate for your use case. As all components of Shibboleth are highly configurable and use cases my vary, we cannot give a final advise here. However, in most cases you will probably choose a field that is unique, persistent and global. A typical choice could be eppn. For more information on properties of name identifiers, see https://wiki.shibboleth.net/confluence/display/CONCEPT/NameIdentifiers!

Within userControls there are three parts. For simplicity, in our example we use just one-to-one mappings and hard-coded values. In real world, you might want to use the full toolset of Typoscript (e.g. CASE, COA, noTrimWrap etc.) to set values.

  • allowUser represents (your) decision to accept the user for TYPO3. If this evaluates to 1, the user will be accepted.
  • createUserFieldsMapping is a section that is applied only once, i.e. when a user is auto-imported for the first time.
  • updateUserFieldsMapping is a section that is applied each time shibboleth authenticates an user that is already in the TYPO3 database. It is not run for new users.

In our example, we accept all Shibboleth users. ( allowUser.value = 1 )

In both *UserFieldsMapping sections you can use basically any TYPO3 field that exists in the user table. Take care of the few differences between fe_users and be_users (e.g. admin only exists in be_users).

On auto-import, we set the email address field of the new TYPO3 user to the value transferred in REMOTE_USER. However, we do not update this field later on. This makes sense here, as the source field is also the user ID.

On each subsequent authentication the user record is updated. In our example, only the admin flag is affected by the update. The idea here is to make sure a user is not given the “admin” privilege manually. (Again, this is a decision to be made in accordance to your requirements.)

Important hint: If you want a field to be set in all cases, you have to put the configuration in both sections, createUserFieldsMapping and updateUserFieldsMapping.

Now to a frontend example:

tx_shibboleth {
        FE {
                IDMapping {
                        shibID = TEXT
                        shibID.field = eppn
                        typo3Field = username
                }
                userControls {
                        allowUser = TEXT
                        allowUser.value = 1
                        createUserFieldsMapping {
                                email = TEXT
                                email.field = mail

                                usergroup = TEXT
                                usergroup.value = 1

                                name = TEXT
                                name.field = Shib-realname
                        }
                        updateUserFieldsMapping {
                                email = TEXT
                                email.field = mail

                                name = TEXT
                                name.field = Shib-realname
                        }
                }
        }

Important to note: You have to set the usergroup field for FE users. Creating a user without a usergroup entry doesn’t work, as the user will not be accepted by TYPO3.