White Paper

52N's Security and Geo Rights Management Community

– Position –

Initialization: 2009-05-25

Author: Jan Drewnak, drewnak@52north.org

Scope

This white paper reflects the current position of the “Security & GeoRM” community, of the 52°North Open Source Software Initiative, hereafter called “the community”. It illustrates the current achi evements of the community, gives an outlook on future work, and of research items.

This paper describes no binding roadmap nor is it a specification. Any statement made herein is subject to modification without this paper being updated.

The Community

Our Mission

Two aspects of access control

The two components of the community's name “Security” and “GeoRights Management” describe different views on functionality of a software system that is subject to access control mechanisms. While the term ”Security” solely relates to the technical base functions of access control, “GeoRights Management” involves a

“Security”

The term “Security” relates to a solely technical view of access control. Security as we see it is about enforcing access policies during an access attempt from a subject onto a resource, mostly provided by services. The community thus provides a set of components that

a) authenticate subjects (users, other software components) intending to access a protected service so their identity is known (Authentication), and

b) check if the identified subject is allowed to access a resource (Authorization) and permit or deny access.

The main focus of the community still lies on this aspect of access control, mainly for historical reasons. In the beginning of access control for geo-spatial services it didn't matter where the main information items like users, policies, etc. came from, they were “just there” or had to be created by some kind of system administrator. The main problem was the development of the basic functions . As a result of this attitude, the work of the community was not much influenced by (real) geo-spatial problems.

Nevertheless, the security branch is the foundation for any higher-level functions up to the implementation of business-related (in a commercial sense) systems.

“GeoRights Management”

The term “GeoRights Management” is rather less related to infrastructure, processes, protocols or components but more to the user's view on the system and the information items exchanged in such an infrastructure. With the extension from security to GeoRights we start to think about: Where do the policies come from? Which business processes are relevant and need to be supported by additional software?

In the first instance – ie. as we interpret it for this community now – GeoRights Management deals with “dynamic policies” that are derived by licenses and not just statically defined by an administrating person. Service providers usually don't grant permissions to users explicitly but grant licenses, like “private-use” or “commercial” or “no-matter-but-0.1-cent-per-request”, determine linked policies.

Using licenses as a source for access decisions is usually a business function that is requested by state/federal agencies or larger enterprises. In contrast to the “simple” security solutions that can be easily set up and implemented by smaller organization, license based workflows tend to be connected to more stakeholders like accounting systems (and departments!), online shop systems, legal persons and so on.

Especially in this field, we as the body of the community cannot provide an out-of-the-box solution but a basis for comlpex products and a provider for a solution of “simple” use cases like “click-through” license enforcement.

Our Structure

Networking

Products/Software Components

→ Focus on (web?) services providing an interface to resources.

Security

General Architecture

Illustration 1 shows the general security architecture implemented by the community, where access to an OGC Web Service (OWS) from an OWS client is protected involving the fundamental security components Authentication Service , Enforcement Point , and Decision Point .

Compared to direct client-service communication, with the security components added the protected service is not accessible from any other component than the Enforcement Point. Every request to the protected service is intercepted by the Enforcement Point. The Enforcement Point authorizes the request accepting and forwarding it to the protected service (perhaps together with some obligations) or rejecting it according to the specified policies. The decision whether access to a particular resource is permitted or denied is made by the Decision Point that has access to the policies. The decision is then enforced by the Enforcement Point.

A requirement for accurate policy decisions is, that they are based on a proven identity of the requesting party, be it a person or a software component. Thus, the client has to convey some kind of credentials that serve as a proof of identity. Depending on what kind of credentials are accepted by an Enforcement Point implementation, the client retrieves the credentials from the user, eg. with a login dialog, and passes them, together with the request, to the Enforcement Point. In the Community a dedicated Authentication Service specified and developed issueing tickets as a means to prove the requester's identity. But generally any other kind of credentials like plain username and password as used with HTTP Basic Authentication are sufficient to prove identity, as long as the Enforcement Point can interpret them.

Components – 52N Implementations

• Which
• Interfaces
• Features
• Work to be done
• Ideas

Scenarios

List of vivid scenarios, that can be implemented with the existing components. At the bottom of each scenario, outline the possibly missing pieces.

Architecture – Licensing

General

Components – 52N Implementations

• Which
• Interfaces
• Features
• Work to be done
• Ideas

Scenarios

List of vivid scenarios, that can be implemented with the existing components. At the bottom of each scenario, outline the possibly missing pieces.

Future Work

Research Items