Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Summary

AAF Components are all Java(tm) HTTP/S based RESTful services, with the following exceptions:

  • AAF GUI component is an HTTP/S HTML5 generating component.  It uses the same code base, but isn't strictly RESTful according to definition.
  • AAF FS component is a FileServer, and is HTTP only (not TLS), so it can deliver publicly accessible artifacts without Authentication.

Essentials

Technologies required to run AAF

  • Java(tm).  Version 8.121+

    • Oracle Java previous to Oracle Java SE 8 to version 8 Update 121 is vulnerable to "SWEET32" attack.

      1369383 - CVE-2016-2183 SSL/TLS: Birthday attack against 64-bit block ciphers (SWEET32)

  • Cassandra, Version 2.1.14+
  • X509 Certificates (at minimum to support HTTP/S TLS transactions (TLS1.1 and TLS1.2 are default, but can be configured).

Optional Technologies for special cases

  • Build your own Certificate Authority for Bootstrapping and/or Certificate Manager component.
    • openssl
    • bash

Data Definitions

AAF Data Definitions

AAF is Data Driven, and therefore, needs to have some structure around the Initial Data so that it can function.  You will need to define:

  • Your Organization:
    • Example:  Are you a company?  Do you already have a well known internet URL?
      • If so, you should set up AAF Namespaces with this in mind.  Example:

        for "Kumquat Industries, LTD", with internet presence "kumquats4you.com" (currently, a fictitious name), you would want all your AAF Namespaces to start with:

        "com.kumquats4you" 
    • The examples all use

      "org.osaaf"

      However it is recommended that you change this once you figure out your organizations' structure.
  • Your AAF Root Namespace
    • This can be within your company namespace, i.e. 

      "com.kumquats4you.aaf"

      but you might consider putting it under different root structure.
    • Again, the bootstrapping examples use:

      "org.osaaf.aaf" 
       
  • While creating these, recognize that 
    • 2nd position of the Namespace indicates company/organization
    • 3rd+ position are applications within that company/organization

      "com.kumquats4you.dmaap"

      Following this "positional" structure is required for expected Authorization behavior.


ILM (Identity Lifecycle Management)

Neither Authentication nor Authorization make any sense outside the context of Identity within your Organization.

Some organizations or companies will have their own ILM managers.

  • If so you may write your own implementation of "Organization"
  • Ensure the ILM of choice can be access real-time, or consider exporting the data into File Based mechanism (see entry)

AAF comes with a "DefaultOrganization", which implements a file based localization of ILM in a simple text file

  • Each line represents an identity in the organization, including essential contact information, and reporting structure 
  • This file can be updated by bringing in the entire file via ftp or other file transfer protocol, HOWEVER
    • Provide a process that
      • Validates no corruption has occurred
      • Pulls the ENTIRE file down before moving into the place where AAF Components will see it.
      • Take advantage of UNIX File System behaviors, by MOVING the file into place (mv), rather than copying while AAF is Active
  • Note: This file-based methodology has been shown to be extremely effective for a 1 million+ Identity organization

TBA-how to add an entry

TBA-what does "sponsorship mean"

Initializing Default Implementation

This is recommended for learning/testing AAF.  You can modify and save off this information for your Organizational use at your discretion.

Extract Sample Configuration

On your Linux box (creating/setting permissions as required)

mkdir -p /opt/app/osaaf

cd /opt/app/osaaf

# Download AAF_sample_config_v1.zip (TBA)

jar -xvf AAF_sample_config_v1.zip

Create your own Certificate Authority

Note: This can be skipped if you plan on utilizing your own Certificate Authority mechanism through JSCEP, but you will need to obtain your first Certificates manually all the same


IMPORTANT!  The Identities you use MUST be identities in your ILM.  See /opt/app/aaf/osaaf/data/identities.dat

cd /opt/app/aaf/osaaf/CA

<view README.txt for last minute info>

<view an/or change "subject.aaf" for your needs>. This format will be used on all generated certs from the CA.

bash newca.sh

< available soon ... bash newintermediate.sh <name>>

        \# create an Application Cert

bash manual.sh <your FQDN for this machine> -local


\# create a Personal Cert (for use in Browsers, etc)

bash manual.sh -local

Load Data and/or Meta-Data into Cassandra

Setting this initial Data can be done directly onto Cassadra using "cqlsh" using the following "cql" files:

  • init<version>.cql (whatever is latest in the "zip" file)
  • osaaf.cql
          This file contains initial Authorization Structures, see AAF Data Structures. 
                This is where you would modify your own initial Structures.

Build Source

(if not done already)

Run Java

Note: If you have a Kubernets requirement (support), it is STILL RECOMMENDED you run AAF as stand-alone Java Components on your system, and work out any modifications required BEFORE trying to run in Kubernetes.

TBA <java -Dcadi_prop_files=/opt/app/osaaf/etc/org.osaaf.locator.props -cp <path> File>




  • No labels