150 likes | 251 Views
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
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 - ?