docs/sections/installation/AAF_7_Optional.rst

   1 .. contents::
   2    :depth: 3
   3 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   4 .. http://creativecommons.org/licenses/by/4.0
   5 .. Copyright © 2017 AT&T Intellectual Property. All rights reserved.
   6
   7 =======================================
   8 Optional Technologies for special cases
   9 =======================================
  10
  11  - Build your own Certificate Authority for Bootstrapping and/or Certificate Manager component.
  12    - openssl
  13    - bash
  14
  15 Data Definitions
  16 ----------------
  17
  18 AAF Data Definitions
  19
  20  - 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:
  21
  22 Your Organization:
  23  - Example:  Are you a company?  Do you already have a well known internet URL?
  24  - If so, you should set up AAF Namespaces with this in mind.  Example:
  25
  26  - for "Kumquat Industries, LTD", with internet presence "kumquats4you.com" (currently, a fictitious name), you would want all your AAF Namespaces to start with:
  27
  28 "com.kumquats4you"
  29 The examples all use
  30
  31 "org.osaaf"
  32
  33 However it is recommended that you change this once you figure out your organizations' structure.
  34 Your AAF Root Namespace
  35 This can be within your company namespace, i.e.
  36
  37 "com.kumquats4you.aaf"
  38
  39 but you might consider putting it under different root structure.
  40 Again, the bootstrapping examples use:
  41
  42 "org.osaaf.aaf"
  43
  44 While creating these, recognize that
  45 2nd position of the Namespace indicates company/organization
  46 3rd+ position are applications within that company/organization
  47
  48 "com.kumquats4you.dmaap"
  49
  50 Following this "positional" structure is required for expected Authorization behavior.
  51
  52
  53 ILM (Identity Lifecycle Management)
  54 Neither Authentication nor Authorization make any sense outside the context of Identity within your Organization.
  55
  56 Some organizations or companies will have their own ILM managers.
  57
  58 If so you may write your own implementation of "Organization"
  59 Ensure the ILM of choice can be access real-time, or consider exporting the data into File Based mechanism (see entry)
  60 AAF comes with a "DefaultOrganization", which implements a file based localization of ILM in a simple text file
  61
  62 Each line represents an identity in the organization, including essential contact information, and reporting structure
  63 This file can be updated by bringing in the entire file via ftp or other file transfer protocol, HOWEVER
  64 Provide a process that
  65 Validates no corruption has occurred
  66 Pulls the ENTIRE file down before moving into the place where AAF Components will see it.
  67 Take advantage of UNIX File System behaviors, by MOVING the file into place (mv), rather than copying while AAF is Active
  68 Note: This file-based methodology has been shown to be extremely effective for a 1 million+ Identity organization
  69 TBA-how to add an entry
  70
  71 TBA-what does "sponsorship mean"
  72
  73 Initializing Default Implementation
  74 This is recommended for learning/testing AAF.  You can modify and save off this information for your Organizational use at your discretion.
  75
  76 Extract Sample Configuration
  77 On your Linux box (creating/setting permissions as required)
  78
  79 mkdir -p /opt/app/osaaf
  80
  81 cd /opt/app/osaaf
  82
  83 # Download AAF_sample_config_v1.zip (TBA)
  84
  85 jar -xvf AAF_sample_config_v1.zip
  86
  87 Certificate Authority
  88 You need to identify a SAFE AND SECURE machine when working with your own Certificate Authority.  Realize that if a hacker gets the private keys of your CA or Intermediate CAs, you will be TOTALLY Compromised.
  89
  90 For that reason, many large companies will isolate any machines dealing with Certificates, and that is the recommendation here as well... However, this page cannot explain what works best for you.  JSCEP is an option if you have this setup already.
  91
  92 If you choose to make your own CA, at the very least, once you create your private key for your Root Cert, and your Intermediate Certs, you might consider saving your Private Keys off line and removing from the exposed box.  Again, this is YOUR responsibility, and must follow your policy.
  93
  94
  95
  96 IMPORTANT!  As you create Certificates for Identities, the Identities you use MUST be identities in your ILM.  See /opt/app/aaf/osaaf/data/identities.dat
  97
  98 Creating your own Certificate Authority (if desired)
  99 1) Obtain all the Shell Scripts from the "conf/CA" directory which you can get the from the git repo.
 100
 101 For this example, we'll put everything in /opt/app/osaaf
 102
 103 mkdir /opt/app/osaaf/CA, if required
 104
 105 $ cd /opt/app/osaaf/CA
 106
 107 view README.txt for last minute info
 108
 109 view and/or change "subject.aaf" for your needs. This format will be used on all generated certs from the CA.
 110
 111 $ cat subject.aaf
 112
 113 If you will be using PKCS11 option, review the "cfg.pkcs11" file as well
 114
 115 $ cat cfg.pkcs11
 116
 117 $ bash newca.sh
 118
 119 Obviously, save off your passphrase in an encrypted place... how you do this is your procedure
 120
 121 At this point, your Root CA information has been created.  If you want to start over, you may use "bash clean.sh"
 122
 123 Create your Intermediate CAs
 124 2) You do NOT sign regular Cert requests with your Root.  You only sign with Intermediate CA.  The "intermediate.sh" will create a NEW Intermediate CA Directory and copy appropriate Shell scripts over.  Do this for as many Intermediate CAs as you need.
 125
 126 $ bash newIntermediate.sh
 127
 128 creates directories in order, intermediate_1, intermediate_2, etc.
 129
 130 Use the Intermediate CA for creating Service/Identity Certs (can be utilized by Certman with LocalCA)
 131 3) When creating a Manual Certificate, DO THIS from the Intermediate CA needed
 132
 133 $ cd intermediate_1
 134
 135 4) Create initial Certificate for AAF
 136
 137 IMPORTANT!  As you create Certificates for Identities, the Identities you use MUST be identities in your ILM.  See /opt/app/aaf/osaaf/data/identities.dat
 138
 139 To create LOCALLY, meaning create the CSR, and submit immediately, do the following
 140
 141 $ bash manual.sh <machine-name> -local
 142
 143 FQI (Fully Qualified Identity):
 144
 145 <identity from identities.dat>@<domain, ex: aaf.osaaf.org>
 146
 147 To create Information suitable for Emailing, and signing the returned CSR
 148
 149 $ bash manual.sh <machine-name>
 150
 151 FQI (Fully Qualified Identity):
 152
 153 <identity from identities.dat>@<domain, ex: aaf.osaaf.org>
 154
 155 5) Create p12 file for AAF
 156
 157 REMAIN in the intermediate directory...
 158
 159 $ bash p12.sh <machine-name>
 160
 161 Copy initializations to Host Machine
 162 AAF is setup so it can run
 163
 164 On the O/S, using Java
 165 On Docker
 166 On K8s
 167 In each case, even for Docker/K8s, we utilize the File O/S for host specific information.   This is because
 168
 169 Many things are Host Specific
 170 The Hostname required for TLS interactions
 171 Cassandra specific information (when external/clustered)
 172 Logging (if logging is done in container, it will be lost if container goes down)
 173 To make things simpler, we are assuming that the file structure will be "/opt/app/osaaf".  The code supports changing this, but documentation will wait until use cases arises for ONAP.
 174
 175 Steps:
 176
 177 1) Copy "osaaf.zip" to your Host Machine, where osaaf.zip is provided by AAF SME. // TODO POST SAMPLE HERE
 178
 179 2) Copy your "p12" file generated by your CA (see above), and place in your "certs" directory
 180
 181 3) SSH (or otherwise login) to your Docker/K8s Host Machine
 182
 183 4) setup your directories (you might need to be root, then adjust what you need for O/S File Permissions
 184
 185 $ mkdir /opt/app/osaaf
 186
 187 $ cd /opt/app/osaaf
 188
 189 $ mkdir cred logs
 190
 191 $ unzip ~/osaaf.zip
 192
 193 $ mv ~/<p12 file from CA above> cred
 194
 195 $
 196
 197 Unzip the "osaaf.zip" so it goes into the /opt/app/osaaf directory (should have "etc", "data", "public" and "certs" directories)
 198
 199 4) Modify "org.osaaf.props" to have
 200
 201
 202
 203 Load Data and/or Meta-Data into Cassandra
 204 Setting this initial Data can be done directly onto Cassadra using "cqlsh" using the following "cql" files:
 205
 206 init<version>.cql (whatever is latest in the "zip" file)
 207 osaaf.cql
 208 | This file contains initial Authorization Structures, see AAF Data Structures.
 209 | This is where you would modify your own initial Structures.
 210
 211 Build Source
 212 (if not done already)
 213
 214 Run Java
 215 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.
 216
 217 TBA <java -Dcadi_prop_files=/opt/app/osaaf/etc/org.osaaf.locator.props -cp <path> File>
 218