Differences between revisions 3 and 16 (spanning 13 versions)

Task Doms Auth system

Title: Doms Auth system

State: Not started

Time used

Time estimated: 20md in DigiRes, 7md in IT Web, 2x14 md in IT Service, ? in IT Maintenance

Description

The doms auth system is responsible for ensuring that no user can access files without sufficient credentials. Furthermore, parts or entire doms record should be blockable with the auth system.

The Auth system is based around Fedora as the Authorization provider. Object policies are expressed in Fedora in XACML. There is meant to be a number of Authentication providers.

The auth system is layered. Authentication happens on the outer layer, against whatever Authentication providers we link with. The trusted services on the outer layer establishes the users roles/attributes. These are then communicated to Fedora, which evaluates them against the authorization policy.

With this design, we can have a single Authorization provider, and thus one place to define policies, but integrate with numerous signon systems.

The following components need to be established.

Some service that converts user roles into credentials that Fedora can work with.
- This could be done with a temporary LDAP server, or similar, or some magical stuff directly with Fedora. KFC has expressed views on this, so the design will not be completed without him
A system that transparently handles the credentials when requesting files from bitstorage
A system that transparently handles the credentials when displaying Doms objects in Summa

RolesForFedora

Bitstorage

Summa display

Estimates

Components

Doms Auth service (DigiRes)
- Creating service, and making API (2B)
- Speaking with Fedora (2B)
- Creating users from roles (included in estimate for temp user db)
Temp user db (DigiRes)
- Create service and memory database (5B)
Fedora (DigiRes)
- Auth filter that speaks with Temp user db (3C)
- Filterchain for above filter, and LDAP to our AD (2C)
Auth.php (IT service) (2x14md)
- SimplSaml server
- Php flow
- Coordination (C because more unclear in design) (DigiRes) (1C)
Apache (IT Maintenance)
- Establish a apache http server with mod_auth_cas
- Coordination (A because standard task) (DigiRes) (1A)
Ip2Roles (DigiRes)
- Backend, propably Derby Embedded DB (2C)
- Rest Service (Services are 2B, for project creation, interface creation, and using the build framework) (2B)
- The following two tasks will be done by IT Web, by promise of HL
  - Discover correct tech for making frontend for administrator. D because we might not find a good tech. (2D)
  - Impl frontend. B because if we find a good tech, there are few risks. (5B)

Sub tasks

Title

State

Time used

Time estimated

Documentation

Progress history

Iteration

Time used

Status

Notes

Tasks adressed

-  ⇤ ← Revision 3 as of 2010-06-03 08:47:41 → 
  Size: 4115
  Editor: abr
  Comment:
+   ← Revision 16 as of 2010-06-10 13:07:27 → ⇥
  Size: 4873
  Editor: abr
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 6:
-Line 17:
+Line 16:
- Time estimated::
+ Time estimated:: 20md in DigiRes, 7md in IT Web, 2x14 md in IT Service, ? in IT Maintenance
 Line 20:
-Line 23:
+Line 22:
+The doms auth system is responsible for ensuring that no user can access files without sufficient credentials. Furthermore, parts or entire doms record should be blockable with the auth system.
 Line 24:
-The doms auth system is responsible for ensuring that no user can access files without sufficient credentials. Furthermore, no doms record should  be viewable without the nessesary credentials. These are two different requirements.
+The Auth system is based around Fedora as the Authorization provider. Object policies are expressed in Fedora in XACML. There is meant to be a number of Authentication providers.
 Line 26:
-. Auth check on bitstorage access
 1. Auth check on long post viewing
+The auth system is layered. Authentication happens on the outer layer, against whatever Authentication providers we link with. The trusted services on the outer layer establishes the users roles/attributes. These are then communicated to Fedora, which evaluates them against the authorization policy.
-Line 29:
+Line 28:
-== Bitstorage auth design ==
+With this design, we can have a single Authorization provider, and thus one place to define policies, but integrate with numerous signon systems.
-Line 31:
+Line 30:
-This design has been worked out between Mads (INITIALS), Per (INITALS) and abr. Jhlj has been informed of some of the design, but need to sign of on the final version.
+The following components need to be established.

 1. Some service that converts user roles into credentials that Fedora can work with.
  This could be done with a temporary LDAP server, or similar, or some magical stuff directly with Fedora. KFC has expressed views on this, so the design will not be completed without him
 1. A system that transparently handles the credentials when requesting files from bitstorage
 1. A system that transparently handles the credentials when displaying Doms objects in Summa


=== RolesForFedora ===
-Line 35:
+Line 42:
-The design is as follows:

 1. Each file in bitstorage is assigned a permanent URL
 1. An Apache server is set up to handle these URLs
 1. This apache server has the nessesary rewrite filters set up to forward the request to a php application.
 1. Php application ('''Written  by IT service''')
  1. Extract Wayf credentials from the user. There might be no credentials, which is not yet an error.
  1. Extract the user IP (or domain), and set this as a user property
  1. Call the DomsAuth service with the permanent URL and the credentials if any (and the IP property), ('''Written by IT Digitale Ressourcer''')
   1. Doms Auth lookup the corresponding file object in fedora, and attempts to read this with the supplied credentials. If succesful, true is returned. Else false. 
  1. If the DomsAuth service gave false and the user had no WAYF credentials, redirect the user to a wayf login page.
  1. If the DomsAuth service gave false, but the user had WAYF credentials, report error.
  1. If the DomsAuth service gave true, stream the file through the php app to the user
   1. Stream app. This app streams the given file from whereever into the php script so the user can read it. ('''Written by IT Maintenance''')

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, and using a round robin dns would split the load.
+=== Bitstorage ===
-Line 54:
+Line 45:
+=== Summa display ===


== Estimates ==

Components
 * Doms Auth service (DigiRes) 
  * Creating service, and making API '''(2B)'''
  * Speaking with Fedora '''(2B)'''
  * Creating users from roles (included in estimate for temp user db)
 * Temp user db (DigiRes)
  * Create service and memory database '''(5B)'''
 * Fedora (DigiRes)
  * Auth filter that speaks with Temp user db '''(3C)'''
  * Filterchain for above filter, and LDAP to our AD '''(2C)'''
 * Auth.php (IT service) '''(2x14md)'''
  * SimplSaml server
  * Php flow
  * Coordination (C because more unclear in design) (DigiRes) '''(1C)'''
 * Apache (IT Maintenance)
  * Establish a apache http server with mod_auth_cas
  * Coordination (A because standard task) (DigiRes) '''(1A)'''
 * Ip2Roles (DigiRes)
  * Backend, propably Derby Embedded DB '''(2C)'''
  * Rest Service (Services are 2B, for project creation, interface creation, and using the build framework) '''(2B)'''
  * The following two tasks will be done by IT Web, by promise of HL
   * Discover correct tech for making frontend for administrator. D because we might not find a good tech. '''(2D)'''
   * Impl frontend. B because if we find a good tech, there are few risks. '''(5B)'''
-Line 60:
+Line 81: