| Infrastructural
Network Services |
| Attendees: Roland Hedberg UmU, Leif Johansson SU, Magnus Jonsson UmU, Anders Liljegren UU, John Westerlund LU and Torbjörn Wiberg UmU. 1. Initial Construction Package. Decision:Torbjörn
Wiberg decided around 1 June to give go ahead to Roland Hedberg to start
working on an Initial Construction Package for SPOCP, consisting of
2. Status of the initial construction package The initial construction package has been available in alfa for restricted testing since the end of august. It is tested by two student administrative application projects: NyA - a admittance system for higher education and Ladok on Web - a student record self service application. It is also used by Roland Hedberg in his exim mail server. 3. Structure of Rules and Queries Decision: Rights expressed in both Rules and Queries of SPOCP shall have the structure of a "Subject" performing an "Action" on a "Resource". A Rule can be constrained and the right requested in a Query may be supported by information whose purpose is to lift possible constraints. A typical example is a right that has a time-constraint associated with it. 4. Restricted S-expressions and the Policy Engine Decision: The basis of the Authorisation Server is that
Unrestricted S-expressions are generalised lists, a data structure for representing complex data. The elements of a these generalised list is either byte-strings ("octet-strings") or (simpler) S-expressions. Restricted
S-expressions in SPOCP shall be: The top level tag in a rule or query must be "spocp". This tag and the tags of the sub-S-expressions are names or types of the expressions. Some are predefined and are interpreted by the Policy Engine. Others only have a meaning for the application and are treated according to the evaluation rules for S-expressions. Action Item d1.1: Specify further details of the syntax (not discussed here) that are still not decided by the Design Team. A rule or a right must have the form: (spocp (resource ...) (action ...) (subject ...) ) This structure (including the order of the sub-S-expressions) is fixed and is assumed by the Policy Engine. The syntax of the sub S-expressions are given by the definition of "Restricted S-expressions" as a tag followed by a sequence of restricted S-expressions, complemented with the added escape possibilities we, for now, call external references. The Policy Engine evaluates the external references in a query (Q) or a rule (R) when it is reached in the "less-permissive" preorder evaluation. As soon as a rule is found for which Q<=R, the Policy Engine returns "Allow". If no such rule is found the Policy Engine returns "Deny". This means that anything that is not explicitly permitted is forbidden. Negative permissions, limiting the applicability of positive permissions, are not supported. Given
two lists
if( taga != tagb ) return DENY ;
for( i = 0, j = 0 ; i <= n && j <= m ; ) {
if( isExternalReferens( ai ) == TRUE ) {
if( externalReferens( ai ) == TRUE ) {
i++ ;
continue ;
}
else return DENY ;
}
if( isExternalReferens( bj ) == TRUE ) {
if( externalReferens( bj ) == TRUE ) {
j++ ;
continue ;
}
else return DENY ;
}
if( ai <= bj ) {
i++ ;
j++ ;
}
else return DENY ;
}
if( j == m ) return ALLOW ;
else return DENY ;
The semantic of the sub-S-expression parts is application specific and is of no concern to the Policy Engine. It only analyses and compares the syntactic structure of the S-expressions. To make sense however, the semantic of the sub-S-expression parts should be such that, if a query is "less-permissive" than a rule (that is what you ask for is within the scope of what is permitted), it is reasonable to "Allow" the Subject of the query to carry out its Action on its Resouce. 5. External References The Policy Engine is designed to use backend plugins to evaluate external references. In the Initial Package, plugins for LDAP, flat files, gdbm and time constraint evaluators have been defined. The external reference in a rule is often parameterized, and the parameter values are given in the query. In the rule there could for instance be a reference to a directory attribute value for the subject (typically a urn-template). To look that up in the directory, the information on the subject given in the query is needed. So far the Design Team has not identified the need for any further backend plugin, but we expect that such needs might well appear as tests become more intense. External references can appear in the S-expression anywhere where a byte-string can appear, with some exceptions. It can not be the 'tag' of a list and it can not appear in what is called star expressions (not discussed in this document).When, during the test for Q<=R, an external reference is found in a rule, the corresponding plugin is called to evaluate the reference. The result is either true or false. True means "sofar nothing indicates that the response to the request shall be Deny" and false means "terminate the evaluation with the response Deny". The Design Team held a non-conclusive discussion of the advantages of the extra complexity and power introduced by external references, and the possibility of adding several layers of indirection, versus the advantages of the overview it is possible to achieve with the simplicity of the S-expressions. In particular when it is possible to express the constraint in an S-expressions one need to be verye clear about the reason for using an external information service instead. Another question is: how powerful external reference possibilities shall be provided. Action Item d1.2: Take a position on how external references are best used and document it. Action Item d1.3: Decide the urn-structure for external information services 6. The ABC of Authorisation The preliminary design was based on the assumption that the SPOCP-server shall have three protocols/APIs for communication. One Administrative, one Backend and one Client protocol/API. Decision: SPOCP shall be designed and implemented after the ABC-model. 7. The C-protocol/API In the Initial Package, the C-protocol is implemented in both SAML/SOAP in HTTP and as a simple text based protocol using canonical S-expressions on an internet port or a unix domain socket. Furthermore the Policy Engine is constructed as a library module which means that it can be tightly integrated with applications that for some reason do not want to use TCP to access the policy engine. Decision: SPOCP initially shall use SAML/SOAP in HTTP, later in HTTPS. In the Initial Package, the SPOCP server uses an Apache server as a frontend. This approach has been efficient and provides support for HTTP/HTTPS communication and for parsing SAML. Decision: There is no reason for the moment to reconsider using an Apache server as a frontend. Decision: The Policy Engine shall be available as a library module. Decision: The minimal package shall satisfy:
8. The B-protocol/API Backends for LDAP, gdbm, flat file and the evaluation of time constraints are implemented in the start package. Decision: LDAP shall be the B-protocol. Decision: The Design Team supports Roland in his approach to integrate backends in the Policy Engine rather than communicating through one B-protocol. It shall be noted though, that a new backend requires adding code to the Policy Engine. This addition has to adher to the specified backend API. A new branch of the external references URN tree also has to be defined. The application specific parts of the syntax may also collide with the addition of new Policy Engine related parts of the syntax. 9. The A-protocol/API and the Administrative Tools Suggestion: The Administrative Tools shall be a separate construction package. They shall be designed for three types of administrators: The Expert Adminstrator, who is comfortable with S-expressions and has the responsibility to set up and maintain the rule structure for an application (the "sub-S-expressions" as referred to above). The Application Administrator, who knows the application and the business supported by the application well enough to decide what categories of users shall be allowed to do what in the application. The Role Administrator, who decides what individuals/groups of individuals that shall belong to the different categories of users defined by the Application Administrator. Preliminary Decision: Based on that suggestion, the Design Team decided to assumed the following positions:
Decision: The task of refining this design and carry out the construction work, shall not be assigned to Roland, but to someone else. Action Item 1.4: Carry out the refined design of the A Package. Suggestion: The construction of the Administration Package shall begin as soon as possible (when the Minimal Package has reached alfa). 10. OS Platforms Suggestion: The OS platforms shall be Linux, Windows and maybe Solaris. The Initial Package is developed in Linux. Suggestion: The other platforms are suggested to be a separate OS construction package. The construction of this package shall be prepared by including auto-conf sections in the code from this point on, but the construction shall not start until the design has settled. 11. Delegation and Appointment An initial discussion was held on the subject of delegation and appointment. Action Item D1.5: Suggest a design for delegation. 12. Separate Action Items Action
Item D1.6: Cacheing
|
|
|
