Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Access Control Teleconf 20080509"
(New page: Notes from 20080509 Teleconf Attending: Jim Brian Mary Paul Drummond Markus Valery Bruce David Tony others I missed? Agenda: * Review http://wiki.eclipse.org/Access_Control_in_IdAS. ** S...) |
|||
| Line 17: | Line 17: | ||
* Review http://wiki.eclipse.org/Access_Control_in_IdAS. | * Review http://wiki.eclipse.org/Access_Control_in_IdAS. | ||
** Specifically http://wiki.eclipse.org/Access_Control_in_IdAS#Current_Proposal | ** Specifically http://wiki.eclipse.org/Access_Control_in_IdAS#Current_Proposal | ||
| + | |||
| + | Notes: | ||
| + | * Looking at Policy-Entities.pdf | ||
| + | ** Paul intended this to be a simple proposal and to show how it might help Parity do something they're working on. | ||
| + | * Tony: Bootstrap issue | ||
| + | ** what's the policy on the policy | ||
| + | *** need to make sure we can make policy statements | ||
| + | * David: Where are the enforcement points? | ||
| + | ** Jim: The CP must ensure (whether it has to do it, or the backing store does it) | ||
| + | ** Paul: Agree | ||
| + | ** David: If there's an external enforcement engine, I have other questions. | ||
| + | ** Paul: There is the option of fronting | ||
| + | * David: Can the accessing Entity be in another CP? | ||
| + | ** example: cp entities are entries in a database, but the authenticating identity does not exist in the context. | ||
| + | ** Subject ID must come from somewhere | ||
| + | *** CP can derive it from authN materials | ||
| + | **** an authenticated user can be mapped to a subject id | ||
| + | * AuthZ Subject IDs need to be flexible | ||
| + | ** need to be able to specify roles, groups | ||
| + | *** example: allow anyone from my facebook friends to do X | ||
| + | ** Drummond suggests using UDI for AuthZ subjectID | ||
| + | * What about referential integrity? | ||
| + | ** The CP must be required to ensure authZ subjectID is not re-assignable | ||
| + | *** In some cases, (i.e. when the authZID is provided by another ctx), it's up to the other ctx. | ||
Revision as of 11:16, 9 May 2008
Notes from 20080509 Teleconf
Attending: Jim Brian Mary Paul Drummond Markus Valery Bruce David Tony others I missed?
Agenda:
Notes:
- Looking at Policy-Entities.pdf
- Paul intended this to be a simple proposal and to show how it might help Parity do something they're working on.
- Tony: Bootstrap issue
- what's the policy on the policy
- need to make sure we can make policy statements
- what's the policy on the policy
- David: Where are the enforcement points?
- Jim: The CP must ensure (whether it has to do it, or the backing store does it)
- Paul: Agree
- David: If there's an external enforcement engine, I have other questions.
- Paul: There is the option of fronting
- David: Can the accessing Entity be in another CP?
- example: cp entities are entries in a database, but the authenticating identity does not exist in the context.
- Subject ID must come from somewhere
- CP can derive it from authN materials
- an authenticated user can be mapped to a subject id
- CP can derive it from authN materials
- AuthZ Subject IDs need to be flexible
- need to be able to specify roles, groups
- example: allow anyone from my facebook friends to do X
- Drummond suggests using UDI for AuthZ subjectID
- need to be able to specify roles, groups
- What about referential integrity?
- The CP must be required to ensure authZ subjectID is not re-assignable
- In some cases, (i.e. when the authZID is provided by another ctx), it's up to the other ctx.
- The CP must be required to ensure authZ subjectID is not re-assignable