How to swtich off the SSLAuthFilter
by Dmitri Dolguikh
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
14 years, 1 month
- 1
- 0
Fleshing out the Specification for multi-owner tasks in the BrainBox
by Adam Young
(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.
14 years, 1 month
- 3
- 6