candlepin April 2010

candlepin@lists.stg.fedorahosted.org

9 participants
22 discussions

How to swtich off the SSLAuthFilter
by Dmitri Dolguikh 01 Apr '10

01 Apr '10

It's turned on by default. To turn it off, add to candlepin.conf: sslauth.filter.class=org.fedoraproject.candlepin.servlet.filter.auth.PassThroughAuthenticationFilter and you should be set! -d

1 0

Fleshing out the Specification for multi-owner tasks in the BrainBox
by Adam Young 01 Apr '10

01 Apr '10

(E2) Candlepin should support a multi-owner (multi-org/multi-tenant) model From a data modle perspecitive, we need some way of representing an organization, and the ability to delegate authority down the tree, as well as revoke that authority. I'm going to state the obvious: a system like this will, at some point, have to tie in with a directory server(DS). We'll need to determine what set of information we cache from the DS as well as tree traversal strategy do we read the whole tree on demand or read it up front... do we register for events that change the tree Assuming that we need to continue to run in stand alone (no LDAP) mode for the most part, we want to have an analogue for each of the classes in http://admiyo.fedorapeople.org/PartyPattern.png I know that we have some work being done in the authentication side of things, and I'd like to avoid duplicating effort there. 1. As a client, I would like to create the consumer for a specified owner. This says to me that a person in an organiztion higher in the tree needs to create one for an organization at the same level or lower in the tree. 2. As an on premise admin, I would like to load 2 different "satcerts" for 2 different owners. 3. As a security person, I want to ensure a user from owner 1 can not access data for owner. 4. As a security person, I want to ensure that a consumer from one owner can not access the subscriptions from another owner To do this, we need to filter the enumeration of certain entities based on the organization of a given user. THis is a specific application of the Role-Action-Resource portion of the linked diagram. Actions should mostly map to "person with role can read resource" and "person with role can modify resource" And such should be on GET vs PUT, POST, and DELETE. Note that a course grained poicy can be built out of fine grained permissions. Actions (as specified in the above diagram) map to HTTP verbs, and Resources (specified above) map to the URL based Methods on the Resource. We then bundle up groups of those permissions in roles, as well as the ability to dynamically add and remove them from an owner.

3 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

candlepin April 2010