In a previous web log, I explained the basics of Shibboleth as our central authentication- and authorisation infrastructure (AAI). I would like to continue by giving you an indication of the implications within our SAP environment.
- no direct access to our SAP systems (not even Bex Analyzer) is allowed anymore. All access needs to be done via our Enterprise Portal. Once logged in, one can access the SAP environments via a link. This link starts the SAP gui via a sap shortcut file.
- identification on the portal is done via Shibboleth authentication. The portal will further determine what the user is allowed to do.
- Every SAP application outside the portal needs to implement calls to Shibboleth for identification
In this web log I will explain how the latter is done within BSP using our e-recruitment application as an example.
When an applicant wants to use our e-recruitment application, he/she needs to request a userid/password in order to access and protect their own data. This userid/password resides outside the regular authentication system within the K.U.Leuven. This seems contradictive to what we want to achieve with Shibboleth, but there are good reasons for that:
- We don’t want to ‘pollute’ our authentication systems by creating more users than needed. Not every applicant will become an employee.
- Existing students and employees can of course apply for jobs. As such it seems reasonable that they use their student/employee userid for accessing the application. The problem with that is the fact that the employee’s contract can end or a student can stop studying (he/she got his/her degree or gave up studying). That implies that he/she doesn’t have any user id anymore and thus has no access to the system. If he/she doesn’t have any access to the system, he/she won’t be able to access their applicant’s data.
Needless to say this isn’t the way to go. Therefore a separate user id/password for e-recruitment was required. Before Shibboleth, the flow looked like this.
- An applicant requested a user id by providing an e-mail address.
- The applicant received the user id by e-mail
- He/she logged in via that user id and password
- The applicant indicated whether he/she was still an active student or employee (meaning he/she had an active userid) or external person. This was needed in order to copy data out of their student or employee file. As long as they were active students/employees, the respective systems were the single source of data for them and the data could only be changed in those systems. Once the student/employee was no longer active or the applicant was an external person, the data could be changed in the e-recruitment system itself.
- If not external, the applicant needed to authenticate. For the student, it was carried out directly against an LDAP server. For the employees, a SAP userid/password was needed
- When authenticated, he/she could continue to fill in their data. Some data though would be automatically copied over and the user couldn’t change that data.
That is all history now. When Shibboleth was introduced, authentication against LDAP (directly) or SAP was no longer allowed. Thus the flow looks like this now:
- An applicant indicates that he/she needs a user id
- The applicant indicates whether he/she is still an active student or employee (meaning he/she has an active userid) or is an external person. This is needed for copying data from their student or employee file. As long as they are an active student/employee, the respective student/employee systems will be the single source of data and that data can only be changed in those systems. Once the student/employee is no longer active, or the applicant is an external person, the data can be changed in the e-recruitment system itself.
- If not external, the applicant needs to authenticate against Shibboleth.
- The applicant provides an e-mail address for receiving the user id
- The applicant receives the user id by e-mail
- He/she logs in via that user id and password
- When logged in, he/she can continue to fill in their data. Some data will be automatically taken over and the user can’t change it.
As you can see, not only the authentication mechanism has changed but also the sequence of actions has changed due to the new CUA.
How did we include Shibboleth authentication?
It’s really quite simple as such. An applicant clicks on the button to request a userid for e-recruitment and indicates that he/she is still an active student/employee. In the oninputprocessing we put the following code.
First we need to determine what the URL is of the e-recruitment application. We want to prevent hard coded URLs
CALL METHOD runtime->construct_bsp_url EXPORTING in_application = runtime->application_name in_application_ns = runtime->application_namespace IMPORTING out_local_url = url.
The next page will be the one where the applicant needs to provide an e-mail address CONCATENATE url '/' 'email.htm' INTO url.
Some extra params needs to be provided, since we leave the e-recruitment applicant
CONCATENATE url '?extraparam=' extraparam INTO url.
Now we need to know the name of the server
sname = request->get_header_field( '~server_name' ).
Now we compose the Shibboleth authentication URL with the target e-recruitment page (e-mail) as param
CONCATENATE 'https://' sname '/subdir/Shib?target=https://' sname url INTO url.
And we call that page
navigation->goto_page( url ).
That’s it. When the applicant has been authenticated they don’t automatically see the e-mail page. We need to do some extra authorisation checks in the oninitialisation. As you may remember, Shibboleth only covers the identification and authentication. The authorisation is the responsibility of the application. Shibboleth will provide HTTP headers in order to help you.
We get the userid
application->userid = request->get_header_field( 'Shib-Person-uid' ).
And the type of user type_user = request->get_header_field( 'Shib-EP-UnscopedAffiliation' ).
Depending on the type of user we need to check if the applicant has role X or Y. Why do we need to check this? If we take data over from their employee/student file we want to make sure that the user has enough permission to access the relevant application.<
IF type_user CS 'student'. CALL FUNCTION 'Z_some_auth_check_FM' EXPORTING uname = userid agr_name = 'role_for_students' IMPORTING valid = valid. ELSE. CALL FUNCTION 'Z_some_auth_check_FM' EXPORTING uname = userid agr_name = 'role_for_personnel' IMPORTING valid = valid. ENDIF. IF valid NE 'X'. navigation->goto_page('no_authorisation.htm' ). ENDIF.
