|
Size: 4349
Comment:
|
← Revision 16 as of 2010-06-10 13:07:27 ⇥
Size: 4873
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| Time used:: <<BR>> | Time used:: |
| Line 16: | Line 16: |
| Time estimated:: <<BR>> | Time estimated:: 20md in DigiRes, 7md in IT Web, 2x14 md in IT Service, ? in IT Maintenance |
| Line 21: | Line 22: |
| 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 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 23: | Line 24: |
| 1. Auth check on bitstorage access 1. Auth check on long post viewing |
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: | Line 26: |
| == Bitstorage auth design == 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 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: |
| The design is as follows: | 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: |
| 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. |
The following components need to be established. |
| Line 38: | Line 32: |
| 1. Each file in bitstorage is assigned a permanent URL 1. An Apache server is set up to handle these URLs |
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 |
| Line 41: | Line 37: |
| User GETs a perm url 1. Apache -> url_rewrite the requests and forward it to php app 1. Php application 1. Invoke IP2RolesMapper to get user roles. 1. Invoke Doms Auth Checker(url, roles) to see if the IP roles are enough to get the file 1. If no: 1. Extract Wayf credentials from the user, by redirecting him to the WAYF page. 1. Invoke Doms Auth Checker(url, creds) to see if the file is assesible with the creds 1. if no: 1. Send Unauthorized error 1. Invoke URL2FileMapper to get a file location. 1. Open this file. 1. (Request file mime-type from Fedora) 1. Stream it to the user. |
|
| Line 56: | Line 38: |
| 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. | === RolesForFedora === |
| Line 58: | Line 40: |
| === IP Roles are enough === | |
| Line 60: | Line 41: |
| {{attachment:auth2.jpeg}} | |
| Line 62: | Line 42: |
| === Wayf creds needed === | === Bitstorage === |
| Line 64: | Line 44: |
| {{attachment:auth1.jpeg}} | |
| Line 66: | Line 45: |
| === No creds good enough === | === Summa display === |
| Line 68: | Line 47: |
| {{attachment:auth3.jpeg}} | == 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)''' |
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)
- Apache (IT Maintenance)
- Establish a apache http server with mod_auth_cas
Coordination (A because standard task) (DigiRes) (1A)
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 |