Differences between revisions 11 and 12
Revision 11 as of 2010-06-07 13:31:19
Size: 4723
Editor: abr
Comment:
Revision 12 as of 2010-06-07 13:33:38
Size: 4742
Editor: abr
Comment:
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
 Time estimated::  Time estimated:: 25md in DigiRes
 

Task Doms Auth system

Title
Doms Auth system

State
Not started

Time used

Time estimated

25md in DigiRes

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.

  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
  2. A system that transparently handles the credentials when requesting files from bitstorage
  3. 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 Darwin Embedded DB (2C)

    • Rest Service (Services are 2B, for project creation, interface creation, and using the build framework) (2B)

    • 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

Tasks/22 (last edited 2010-06-10 13:07:27 by abr)