Products & Technology
News & Media
Fusion Technology Products
There are a number of built-in mechanisms that ensure the authenticity of an SRB User: challenge response mechanism (password is not sent across the network), Grid Security Infrastructure (using public and private keys being compatible with the Internet Engineering Task Force standard Generic Security Service API (GSS-API)), and Kerberos (a sophisticated ticket management mechanism to provide single sign-on for multiple networked services). When using SRB Gateways, Administrators are free to set up any supported authentication mechanism for their end-users, such as the integration with Microsoft Active Directory (AD) or Lightweight Directory Access Protocol (LDAP).
Access Control Lists:
Access is controlled on Data Objects, Collections, Resources, and Metadata Attributes. There are various levels of access for each object ranging from 'null' (no access) to 'all' (full access). A fine-grained security mechanism enables access control on a per-User-level. In order to ease User and access control management, access can also be controlled for entire SRB Groups or Domains.
Once end users are authenticated, SRB performs authorization services on every SRB Object that is requested. This ensures that users gain access only to the appropriate objects. The level of access may vary depending on the ACL
SRB employs an additional authorization mechanism where data-sharing Tickets can be sent out to internal or external SRB Users. The Ticket then grants controlled access to Data Objects or entire Collections. Additional restrictions such as time limits and limits on the number of accesses can be built into every ticket.
SRB employs an extensible architecture for various encryption mechanisms: Grid Security Infrastructure (GSI) and Kerberos. With GSI and Kerberos, data can be encrypted during transfer. Other mechanisms may be bundled with SRB to encrypt data during storage.
Users within an SRB Federation have certain roles assigned to them and there is only one SRB User who has the power to do and see everything, the Super User. Other Users can be designated to manage a subset of the Federation and there are Users who can be assigned to manage Data Collections and Users who are just data readers. In order to ease the administration of an SRB Federation, SRB Administrators can create Domains and Groups. ACLs can then be created referencing SRB Domains and Groups.
Every transaction within an SRB Federation can be audited (if enabled). An audit trail will typically contain information such as date of transaction, success or error code, User performing transaction, type of transaction, and notes. The audit trails are just like everything else stored inside MCAT and can therefore be easily queried and filtered. This guarantees the integrity of the data and enables organizations to maintain compliance records.
©2013 General Atomics. All rights reserved. |