• Tasks
• 22
• DesignDocument

Design of Doms Auth system Task

This design has been worked out between MV, PDJ, JRG and ABR. JHLJ has been informed of some of the design, but need to sign of on the final version.

The design here is for the system guarding the bitstorage.

Bitstorage protection

The design is as follows:

Components:

• Doms auth checker: Service for checking credentials against the policy in doms. Author IT Digitale Ressourcer
• IP2RolesMapper: Service for mapping user ip to a set of roles. Auther Unknown.
• URL2FileMapper: Service for mapping a permament url to a file. Authro IT Drift
• PHP main app: Service for handling the flow between the services. Auther IT Service
• Apache server: Server for housing the php app, and handling the perm urls. Use URL_rewrite to forward requests to php.
• Each file in bitstorage is assigned a permanent URL
• An Apache server is set up to handle these URLs

User GETs a perm url

1. Apache -> url_rewrite the requests and forward it to php app

2. Php application
   1. Invoke "IP2RolesMapper" to get user roles.
   2. Invoke Doms Auth Checker(url, roles) to see if the IP roles are enough to get the file
   3. If no:
      1. Extract Wayf credentials from the user, by redirecting him to the WAYF page.
      2. Invoke Doms Auth Checker(url, creds) to see if the file is assesible with the creds
      3. if no:
         1. Send Unauthorized error
3. Invoke URL2FileMapper to get a file location.
4. Open this file.
5. (Request file mime-type from Fedora)
6. Stream it to the user.

It can be seen that the php app will become a bottleneck. There are several designs that could work around this. Having several identical apache servers with identical php apps, and using some sort of load balancing would work.

IP Roles are enough

Wayf creds needed

No creds good enough

Problems

Summa

There are a few problems with the above design. Because the system depends on WAYF, and WAYF depends on browser redirects, it is impossible to embed the permanent urls in a non-WAYF compatible application. For example, you cannot put a picture in a <img/> tag. Just as seriously, you cannot stream the content in any way, as the application will be redirected to the wayf page.

This will, at present, bite us for Summa presentation. Summa want's to be WAYF enabled, but is not there yet. Summa search is a java webservice, and can thus perform the same tasks as the php app above. We could therefore solve the problem by allowing Summa to take the role of the php application for presentation, while maintaining the php application for link resolution. The problem here, of course, is that we duplicate functionality, with all the risks this entails.

Other Auth systems

We will have to support other auth systems than WAYF and IP. These must be worked into the design. The design is simple

1. Get user roles from some system
2. Check roles against doms
3. If good:
   1. Stream file
4. Else:
   1. Try next user role system

The big decision is in which order to check. Since WAYF works by redirecting the user to a login page, WAYF will always be the last way to authenticate.

Prerequisites and Design Decisions

Required Software and Modules

Resources