You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Differently users might have different privacy requirements for the Subject API.  Security by realm is a new feature in 2.2 which is implements in the JDBC2 source adapter.  Callers can pass in which "realm" the search should take place in, and the source can adjust how the search takes place, what attributes look like, etc.

The use case is a software application using the Subject API has two types of users: authenticated and admin.  If an authenticated user is using the application, then the Subject API should change in two respects:  data should be displayed which is from the authenticated online directory, and when free-form searches take place, it should only search data from the authenticated online directory.  Thus, people who for privacy reasons are not listed in the online directory might not have a name or affiliation searchable or displayed in the application.  If someone is picking a person in the people picker who is not showing data in the authenticated online directory, they will need to be picked by netId or subjectId.  However, admin users should be able to search anyone by name, and should be able to see the full institutional name and affiliation of any user.

To use this with the JDBC source, it is very easy.  In the sources.xml, in addition to configuring the table or view, configure another table or view for another realm.  There can be as many realms as you want to use, but if you use one that is not configured, you will get an exception.  Also, it is a good idea to have a default realm (null), which generally should be the one that requires the fewest permissions (data is least private).

     <init-param>
       <param-name>dbTableOrView</param-name>
       <param-value>tf_person_source_v</param-value>
     </init-param>
     <init-param>
       <param-name>admin__realm__dbTableOrView</param-name>
       <param-value>tf_person_source_admin_v</param-value>
     </init-param>

Then you need to create a separate view for this realm.  The tf_person_source_v would have (among other things):

  • name: name from authenticated directory or netId if none
  • description: name from authenticated directory if exists, netId, subjectId, if active, affiliation/orgOrDept/titleOrSchool from authenticated online directory if exists, list of other authenticed directory affiliations if exist
  • search_description: anything in the description or other names the person has listed as viewable from the authenticated online directory

The tf_person_source_admin_v would have the same columns and data as the tf_person_source_v, with the following exaceptions:

  • name: would be the institutional name from their primary affiliation
  • description: name from primary affiliation, netId, subjectId, if active, affiliation/orgOrDept/titleOrSchool from primary affiliation, list of other affiliations

sdf

  • No labels