Bug 12680 - Shibboleth adaptive config
Summary: Shibboleth adaptive config
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Authentication (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Martin Renvoize
QA Contact: Testopia
URL:
Keywords:
Depends on: 8446 13114 13569
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-31 06:57 UTC by Martin Renvoize
Modified: 2021-04-16 06:58 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2014-07-31 06:57:33 UTC
I wish to enhance the shibboleth system such that you can adapt the config used depending upon some attribute returned from the identity provider.

Use case: Given an academic institution, such a place may have rather differing information on record for students as opposed to staff.  I've had instances where the mapping between attributes and koha fields has differed wildly between these two groups. Given the there is probably an attribute that can differentiate between the two, then we should be able to use that to load a set of mapping specific to that usergroup.

Example intended implementation.

<usesshibboleth>1</usesshiboleth>
<shibboleth selector="affiliation" value="student">
  <matchpoint>userid<matchpoint>
  <mapping>
    <userid is="uid"></userid>
  </mapping>
</shibboleth>
<shibboleth selector="affiliation" value="staff">
  <matchpoint>cardnumber<matchpoint>
  <mapping>
    <cardnumber is="libraryID"></cardnumber>
  </mapping>
</shibboleth>

So, in the above example config, the intention would be for koha to look for an 'affiliation' attribute first and foremost, and then depending upon it's value (student or staff) load the corresponding configuration and continue as per normal.