## Please put instances of this task in the subfolder Tasks/ with name for the number, and subfolders as approproate, e.g. Tasks/X/Y
## If any of the below links or sections are not applicable to your page, then please comment them out rather than deleting
## as they may become relevant later on.
## Headline like "Task Implement Backup"
= Task Doms Auth system =
## Task title
 Title:: Doms Auth system

## Valid states: "Not started", "In progress" and "Finished"
 State:: Not started

## The time used is measured in man days and does not include the time spent on any sub-tasks. As a rule of thumb, time should always be allocated to subtasks, rather than parent tasks. Format: Xmd
 Time used:: 

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

== Description ==
## Add a high level task (goals / sub-goals) description here, sufficiently detailed to provide a background for creation of action descriptions.
## Any available (technical) details goes into the below documentation pages.
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
 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 ===



=== 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 ==
<<PageDicts(Tasks/22/\d+$, Title, State, Time used, Time estimated)>>

== Documentation ==
## The documentation section links to the documentation relevant to this task and its sub-tasks (if any).
##
## The below links will automatically be expanded to page names like "Tasks/X/Y/AnalysisDocument" in your created page.
## This should be a proper default.
##
## DO NOT comment out these links.
 * [[Tasks/22/AnalysisDocument|Analysis Document]]
 * [[Tasks/22/DesignDocument|Design Document]]
 * [[Tasks/22/SystemMaintenanceDocument|System Set-up and Maintenance Document]]

== Progress history ==
<<PageDicts(Actions/,Iteration,Time used,Status,Notes,Tasks adressed,Tasks adressed ~= Tasks/22)>>

## Add information about about the current state of the task here. That is, information about what has been completed so far and
## what outstanding issues are left. Example:
##
##=== 2007-09-13 ===
##Finished the design documentation. A review is needed before this task is completed.
##
##=== 2007-08-25 ===
##Completed requirement specification. We are now ready for writing the design document.