CragAntler
commented
7 years ago Overview and Motivation
Many organizations that generate geospatial data need to make that data more accessible and share it with other organizations. Examples include a) The National Oceanic and Atmospheric Administration’s (NOAA) Big Data Project, b) International disaster response agencies, and c) the Earth Observation Cloud Thread of TB14. Within each of these projects, multiple organizations need to collaborate, i.e., share data and resources in a secure way.
From an IT perspective, such collaborations can be managed using federation. A federation is a collaboration and security context wherein the participants can agree upon and enforce joint discovery and access policies for the resources (data and services) they wish to share.
To address this need in a general, standardized way, NIST and the IEEE have stood-up the NIST/IEEE Joint WG on Cloud Federation: http://standards.ieee.org/news/2017/intercloud_interoperability_and_federation.html One possibility that will be pursued is to define a standardizable Federation Agent that manages resource discovery and access across different administrative domains, i.e., organizations [1].
TB14 is a unique opportunity to directly address the secure collaboration requirements of a current, specific OGC application by prototyping a Federation Agent, and in addition -- by collaborating with the NIST/IEEE Joint WG -- to promote a standardizable Federation Agent that could be used for collaboration management across many other geospatial application domains.
The ABCs of Federation Management
There are several ways to implement federation management, but they must all accomplish the same goals: federated identity management "on the front end", and federated resource management "on the back end" [3]. Users from different organizations may have different types of identity credentials with differing types of identity and authorization attributes. Federated identity management enables these credentials to be "understood", for example, by mapping them to local attribute types. Tools like SAML redirections to a given Identity Provider can help with this. Once a user's identity is established, which resources from the different federation participants are they allowed to discover and use? This must be decided by a joint discovery policy based on agreed upon federation attributes. Likewise, when a service request is made, the Service Provider must be able to validate the user's credentials (wherever they are from) and make an appropriate access decision. Tools like XACML are relevant here. The major challenge, though, is how to integrate these existing "piece parts" into a coherent, user-facing federation model that is easy and intuitive to use [2].
Proposals for OGC TestBed 14
- Identify an OGC TB Sponsor application domain that is inherently distributed and requires secure, distributed collaboration management
- Collaborate with the NIST/IEEE Joint WG to define, prototype and evaluate a general Federation Agent
-
- A draft Federation Agent API is being defined for possible use
- Evaluate the federated agent approach for other geospatial application domains
-
- Support further development and adoption by OGC Sponsors, including government organizations
References
[1] Craig A. Lee. A Design Space Review for General Federation Management Using Keystone. In First IEEE Cloud Federation Management Workshop, UCC 2014, December 2014.
[2] Craig A.Lee. Cloud Federation Management and Beyond: Requirements, Relevant Standards, and Gaps. IEEE Cloud Computing, 3(1):42–49, Jan-Feb 2016.
[3] Craig A. Lee, Marcio Assis, Luiz F. Bittencourt, Stefano Nativi, and Rafael Tolosana-Calasanz. Big Iron, Big Data, and Big Identity. In Advances in Parallel Computing, G. Fox (USA), V. Getov (UK), L. Grandinetti (Italy), G. Joubert (Germany), and T. Sterling (USA), editors, IOS, 2017. To appear.
tomLandry
ingosimonis
Background
Organizations that provide geospatial data are exploring ways to make their information more accessible. This includes sharing data via cloud infrastructure providers (e.g. Amazon Web Services, Google Cloud, and Microsoft Azure). The National Oceanic and Atmospheric Administration’s (NOAA) Big Data Project is one such example.
Migrating to the Cloud and Securing Data
As they migrate to the cloud, organizations are decomposing their stove-piped monolithic applications into loosely coupled “microservices” that take advantage of the horizontal scaling available in cloud architectures. Data is no longer bound to the application, allowing the information to be explored in new and novel ways.
Freeing the data comes at a cost. The application controls designed to protect information from unauthorized access are lost. Exposing the data via published, well-understood interfaces increases opportunities for bad actors to use the data for malicious purposes. These challenges might be addressed as follows:
Challenges Implementing ABAC
Implementing ABAC presents a significant cultural change for organizations. Attribute schemas for both end users and data must be established. This is easier in controlled environments where all end users are known and governance can be enforced. The users and data must then be assigned values for the attribute elements.
In public environments, users may not be known. Tracking these identities is still desirable as the information can provide metrics on who is using the data and how they might better be served. Public identity providers (IDP) (e.g. Facebook, Amazon, and LinkedIn) can identify anonymous users. Onboarding these users presents a challenge. The attributes assigned to users will vary from IDP to IDP. End users may also restrict access to some attributes due to privacy concerns.
Managing Microservices Microservices are managed via API gateways capable of authenticating a client and determining whether that client is authorized to access a requested resource (e.g. web service, cloud service, data, etc). If the client is authorized, an access token will be issued to the calling application. The client application will act on behalf of the user.
The OAuth2 access token provides authorization, but does not natively carry identity information. This can pose a problems for data with fine grain acess control requirements. A Policy Enforcement Point (PEP) may sit behind the API gateway to enforce these policies. It will require the user’s identiy to make authorization decisions. This is further complicated in composed services in which multiple services are called. Each service may have a different values for a given attribute and the values must be aggregated to ensure no service receives data at a higher classification than the lowest cleared service in the chain.
To carry identity, JWT tokens can be included within the OAuth2 token body to carry identity. For composed services, Enterprise Service Buses may be able to track the identities of all services in a chain.