150 likes | 263 Vues
This presentation by Roland Hedberg, showcased at the Advance CAMP in Broomfield, Colorado, on July 2, 2004, delves into the SPOCP framework for privilege management. It covers real-time authorization, integration of external information for access control, attribute-based role management, and distributed authentication. The talk highlights the use of S-expressions for policy expression, the latest updates to SPOCP applications, client libraries in multiple programming languages, and the architectural elements necessary for effective privilege management across various platforms and use cases.
E N D
Presentation at Advance CAMP Authority Architecture – Broomfield, Colorado July 2, 2004 by Roland Hedberg <roland@catalogix.se> Privilege Management and Spocp
What's SPOCP • Attribute based 'real-time' authorization server • Simple query based protocol • Made to use external information resources • Uses S-expressions to express policies and requests for permissions. Built around the '<=' operation. • Returns Yes/No and, if configured so, additional information together with a Yes
Place in the chain SPOCP LDAP Application SPOCP User SQL PROGRAM
Where are we right now ? • Latest version 2.1.4 • Getting real-time usage experience • Working on the administrative interface • Spocpfied applications: Postfix, uPortal, OpenLDAP • Access modules: Apache, PAM • Local applications: NyA, LpW, .... • Non-AuthZ usages: information access, certificate verification, route daemon • Client libs: C, Java, Python, Perl
Heads-up • Message based 'meta directory tool' • We are building a 'meta directory tool' based on XMPP as message passing system • RDF as format for update information • Spocp as message policy server • SSH • Implement SPOPC support in auth.c:allowed_user. Investigate generalization of the authorized_keys file possibly in conjunction with a generalized .k5login mechanism in Heimdal. • Heimdal • SPOCP-support in kadmind through general authorization plugin mechanism. SPOCP-support in the kdc (general ticket policy). Look at generalizing the .k5login file.
Administrative interface • What about it ?
Baseline • Privilege management system interface based on 'roles' • A role is a convenient 'handle' for a set of attribute-values. • Easier to understand and relate to • 'Roles' are assigned/constructed by administrators, their names (if they have any) are only valid in the context of the privilege management system. • Access control system based on attribute values and constraints.
In Spocp terms • Role ~= Boundary condition expression • Logical operators 'AND', 'OR' and 'NOT' • Boundary condition = relationship between objects or a constraint • adm-group := "localgroup:{//uid[1]}:adm:${0}" • rbl := "rbl:{//ip[1]}:blackholes.mail-abuse.org:${0}" • Link to external information resources • Access right = S-expression Policy = S-expression [ bcondexp ]
The way we plan to do it(the default, there are exceptions) • Distributed authentication (CWAA) • A framework for authentication between organizations. It is designed to be independent of the authentication system used within a organization • Uses the CMS (Cryptographic Message syntax) protocol • The Authentication server returns a ticket that contains a ID representing the authenticated party • Web apps only • Distributed authorization (Spocp) • Authorization servers based on affiliation/context • Uses the ID provided by the authN service • Common central Applications publishes the format of the queries they will pose
LDAPset Flatfile Difftime Localgroup RBL Regexp SQL Plugin examples • System • Time • Spocp • Ipnum • Gdbm
Example(“ladok på webb”) • LADOK is a central student administration system • Information about courses • Information about student • Local information • LpW is a set of modules that universities can use in their student portals
LpW -> Spocp queries Query format: (lpw (action <function>)(obj <object>)(subj <ID>)) function = “Adresslista”, “Register”, “Uppfolj”, ... object = course-ID ID = requestor-ID --------------------------------------------------------------------- Local rule: (lpw (action Adresslista)) => (ref lpw-user) “lpw-user” is a locally defined 'role' base on whatever
Example of 'role' definition lpw-user := ldapset: {/lpw/subject/uid[1]} : tonwig1.adm.umu.se; cn=ladokuser,cn=group,dc=umu,dc=se ; cn=person,dc=umu,dc=se ; \0/uniqueMember & {\1$uid & ${0}}
Privilege Management and Spocp – Set of UI's • The end user UI should use roles/groups • In our case roles/groups will be translated into boundary conditions and/or parts of S-expressions • The type of permissions are application dependent (functions). • The owners of the resource defines the delegation order.
Our relation to Signet • “Privilege Management Recipe” - YES! • Privilege Management Toolkit – YES! • Internet2 Middleware integration – ? • Multi-organizational scenarios - ? • Support Group-based PM – YES! • Role and PI as EduPerson attributes - ?