Skip to content
This repository was archived by the owner on Jul 11, 2018. It is now read-only.

Architecture

Jump to bottom
Remold edited this page Aug 31, 2015 · 1 revision

The following picture is the high-level architecture of api.demo.openconext.org

The normal flow:

  1. An SP does an OAuth call to retrieve group members, groups or person information. We will support both OAuth1.0a (two-legged), OAuth2.0 (implicit grant, authorization code grant).
  2. The table service_provider_group_acl is checked to see if the SP has the correct ACL to retrieve groups (getGroups, getGroup) or persons (getPerson, getGroupMembers) for each Group Provider
  3. For the authentication check (e.g. key/secret) API will retrieve the information from the JANUS REST interface.
  4. This call is cached (see the Implementation documentation) because we can't retrieve all metadata with one call (by JANUS design)
  5. Person information is retrieved directly from the LDAP
  6. Either the call is getPerson which means that we go direct to the LDAP (maybe first retrieving the urn identifier from the EB table saml_persistent_id when the query is done with a persistent identifier)
  7. If the call is getGroupMembers we first retrieve all the urn's from Grouper and then get all additional information from the LDAP
  8. If a user grants access to the SP to retrieve his information we store the access tokens in the API database (oauth_access_token & oauth_refresh_token for OAuth2 and oauth1_tokens for OAuth1)
  9. API retrieves Groups from Grouper using the Grouper SOAP interface (combined with custom SQL queries for pagination) wrapped in a native Grouper Java client
  10. If the group is marked as external (based on the Group Provider regular expression configuration in manage) we don't query Grouper.
  11. If there is no ACL for this SP for Grouper we send out an error mail (see Implementation)
  12. If the user has an urn which indicates an External Group Provider then API has to perform two steps
  13. Get the entire External Group Provider information from the Manage configuration table (the decision in step 6 is also based on this) which is cached as it is considered semi-static (see the Implementation documentation)
  14. Check if the user has granted OpenConext (in the Profile application) access to the External Group Provider (who are for now all three-legged OAuth1.0a based). The information about the granted OAuth tokens we get from the EB table group_provider_user_oauth). If this is the case then retrieve the Groups after checking if there is an Group Provider - SP ACL in place.
  15. For all two-legged OAuth group providers we don't need the user consent, so we simply retrieve the groups for the person using the OAuth2 configuration parameters (like key and secret)
  16. Check with SURFteams if the external teams for the user are coupled to a SURFteam. If one of the external teams is linked to a SURFteam then the SURFteam is also added to the returned list of Groups.

We use database integration (for lookups in Engine because of the dual situation where the above implementation is largely duplicated in both os.surfconext (who delegates to EB) and api.demo.openconext.org. See also: https://jira.surfconext.nl/jira/browse/BACKLOG-441

Clone this wiki locally