|
Size: 2448
Comment:
|
Size: 3464
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 21: | Line 21: |
| 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 23: |
| 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. 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. === Components === 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 |
Task Doms Auth system
- Title
- Doms Auth system
- State
- Not started
- Time used
- Time estimated
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.
Components
- 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
Sub tasks
| Title | State | Time used | Time estimated |
Documentation
Progress history
| Iteration | Time used | Status | Notes | Tasks adressed |