NRL Security Architecture:


Nov 2, 2013 (4 years and 8 months ago)


NRL Security Architecture:

A Web Services


?Anya Kim

Naval Research Lab

Washington D.C.

NRL Security Architecture

Initially developed to support a DoD project







NRL Security Architecture

Security Requirements

Information sharing

While each node is autonomous, some information may need to
be shared with coalition partners, law enforcement community,

Uses complex sharing rules based on MOA, coalition participation,
location, roles, etc

Autonomy and survivability

Each node should be able to function (even in degraded mode)
independent of other nodes

Secure data management

Data is coming from various sources and security levels

Label data based on sources, classification (e.g., levels of trust)

Enforce access control based on data labels and requestor credentials

NRL Security Architecture

Architecture Features

Uses web services

Multiple instances of autonomous web service
nodes deployed within a service oriented
architecture (SOA) infrastructure

Each organization maintains its own users

Each organization determines and maintains its own
web service access policy

Cross organizational access policies will be based on
written agreements (MOU, MOA, etc)

NRL Security Architecture

Security Features

Oracle Label Security

Federated A&A Model



Network security *

All data in transit is transmitted across the network in
encrypted mode

Oracle Label Security

Two aspects of data protection:

to data and
data separation

Oracle Label Security (OLS) provides mechanisms
for data protection via access mediation and has
Common Criteria (CC) Evaluation Assurance Level
(EAL) 4.

By using correctly created data labels we can
enforce policies by allowing us to label the data

Oracle Label Security

Use OLS to separate and label data from various
organizations and implement label security policy
that satisfies data owners’ rules and regulations

Regular user application is label unaware, and all data
separation and access mediation is performed by the
OLS that implements the project’s overall label
security policy

User applications (i.e., Web services) do not mediate
access to data. They pass user information to Oracle
and OLS returns data that the user is allowed to read

Federated A&A

Based on a service
oriented architecture

Users access the data via a series of web services

The web apps require the user to authenticate himself
before gaining access to the web pages. Additionally, the
user’s attributes, such as role and organization are
included to provide input to access control decisions

Based on OASIS Security Assertion Markup Language
(SAML) 2.0, and Access Control Markup Language

peer trust relationships rather than multilateral

Provides better flexibility

Federated A&A

SSO/SLO (Single Sign
on, Single Logout)

Users need only to authenticate locally, hence
required to only know one username/password

Reduces password associated risks

Ease of management

Enables each organization to use pre
authentication mechanisms independent of others

Allows organizations to create authorization policies
according to their own policies

Simplifies user management in a dynamic

NRL Security Architecture

Information Flow


NRL Security Architecture

Uses commercial standards

Enables independent nodes to run in degraded
mode if necessary (survivability)

Provides strong authentication and authorization,
while preserving unique security and data sharing
requirements of entities

Is applicable to other areas where security,
information sharing (e.g., need
know) and
survivability are issues