AAF is designed to cover Fine-Grained Authorization, meaning that the Authorizations provided are able to used an Application’s detailed authorizations, such as whether a user may be on a particular page, or has access to a particular Pub-SUB topic controlled within the App.

This is a critical function for Cloud environments, as Services need to be able to be installed and running in a very short time, and should not be encumbered with local configurations of Users, Permissions and Passwords.

To be effective during a computer transaction, Security must not only be secure, but very fast. Given that each transaction must be checked and validated for Authorization and Authentication, it is critical that all elements on this path perform optimally.

• AAF 2.0 RESTful interface
  • Accessing RESTful
• Connecting to AAF
  • Methods to Connect
  • J2EE (Servlet Filter) Method
  • Servlet Code Snippet
  • Sample Servlet (Working example)
  • Java Direct (AAFLur) Method

Image Added

Certificate Manager

Overview

Every secure transaction requires 1) Encryption 2) Authentication 3) Authorization.  

• HTTP/S provides the core Encryption whenever used, so all of AAF Components require HTTP/S to the current protocol standards (current is TLS 1.1+ as of Nov 2016)
• HTTP/S requires X.509 certificates at least on the Server at minimum. (in this mode, 1 way, a client Certificate is generated)
• Certificate Manager can generate certificates signed by the AT&T Internal Certificate Authority, which is secure and cost effective if external access are not needed
• These same certificates can be used for identifying the Application during the HTTP/S transaction, making a separate UserID/Password unnecessary for Authentication.
• Authentication - In order to tie generated certificates to a specific Application Identity, AAF Certificate Manager embeds a CSO MechID in the Subject.  These are created by AT&T specific Internal Certificate Authority, which only generates certificates for AAF Certman.  Since AAF Certman validates the Sponsorship of the MechID with requests (automatically), the end user can depend on the mechID embedded in the Subject to be valid without resorting to external calls or passwords.
• ex:
• Authorization - AAF Certman utilizes AAF's Fine-grained authorizations to ensure that only the right entities perform functions, thus ensuring the integrity of the entire Certificate Process

Design and Mechanisms

Use CMAgent for Artifact Management

Preparation

Use Latest CADI Jar File -  Get it from Maven Central ( Open Sourced Version)

Creation

IMPORTANT! if you are using Self-Renewal processes, you MUST include "jks" for Types

...

2016-07-28T09:37:48.455-0500: Call to AAF Certman successful a123@myapp.onap.org, xyz.com

Creating & Deploying Certificates With Certman

• Step 1: Prerequisites
• Step 2: Create Artifacts
• Step 3: Create/Assign Permission
• Create Certman Permission
• Grant Certman Permission to a Role
• Step 4: Deploy/Install Certificates
• Notes:
• Self Renewal
• Setting up Self-Renewal:
• Other uses:
• Step 5:  (optional) Give Your Clients a Truststore File
• Special Cases - Templates
• Vanity URL:
• Domain:

Step 1: Prerequisites

The majority of the setup is for establishing the Application's Identity in AAF and CSO.  This is required to ensure the chain of responsibility from the Certificates to the Sponsor of the MechID.  If your app already uses AAF, that can be skipped.  If a MechID is already established for MechID/Password, that one should be used.  Do not obtain another one.

1. CSO enrolled MechID, because these are about Applications
2. AAF Namespace, so we can ensure only the right people may generate a certificate purporting to be that identity
   
   Steps 1 and 2 are accomplished by following these instructions: OnBoarding
    
3. Install CADI (Latest Version) on boxes where you will use "CMAgent"
1. Java, should be 1.8+ (1.7 still works)
2. Direct Jar Method - this is the best way to use Certificate Manager Agent... 
      

Step 2: Create Artifacts

The App Owner (Should be the Namespace Owner AND the Sponsor of Record of the MechID in CSO Records). Follow these instructions: GUI Instructions

...

• if you want self-renewing certificates, make sure to chose "jks" as an artifact type in step 7
• in step 7, "Directory" must be writable by the user listed in "O/S User". If an application is going to use cadi + certificates, ensure that the process is run by the same user as "O/S User". Information on Unix/Linux file permissions can be found by googling, for instance this post.
• in step 11 ("Copy Artifact"), make sure the list of machines you enter does not contain whitespace
• Alternatively, the GUI can be skipped by following these instructions: Use CMAgent for Artifact Management. In most cases, users should use the GUI instructions above

Step 3: Create/Assign Permission

Use AAF's GUI > Command Prompt to create the following permission and assign it to a role. Pick the GUI for the appropriate environment from Application Authorization Framework

Create Certman Permission

Replace "<ns>" with the name of the application's namespace.

...

perm create com.att.<ns>.certman  aaf   request

Grant Certman Permission to a Role

For instance if, the deployer is an admin of the app's namespace, grant the permission created above to <ns>.admin. For information on how to create a new role, or to assign a user to a role,  see Documentation for Namespace Admins. Replace "<ns>" with the name of the application's namespace. Replace "<some-role" with the name of the deployer's role.

...

-rw-r--r-- 1 abc123 cssari  736 Nov  9 14:42 org.onap.myapp.crontab.sh

Notes:

• Multiple Types are separated by commas: "type=jks,file,script" to get all of them. 
• Great lengths have been taken to ensure that as few special variables are required for Deployment as possible 

Self Renewal

Generating the "scripts" are the key to making Certificates Self-Renewing.  Always add these scripts for Unix Based Systems.  You will have to work your own solution for other O/Ss that don't have "cron".

!! If you use Self Renewal, you MUST have the "jks" files generated!!

Setting up Self-Renewal:

• After deploying certificate above, test the Certificate access with the "check.sh" script
• ALL THE SELF-RENEWAL SCRIPTS ARE "bash" Scripts. If you are not running a bash shell, use "bash" as prefix
• Check the Certificate ID is working

...

#### END org.onap.myapp Certificate Check Script ####

Other uses:

• Once the Certificates are generated, they may be used for certain accesses to Certificate Manager Agent... but only those functions given to the App

...

         REMOTE Show Password 1443.2354ms

Special Cases - Templates

Note: CSO no longer requires special exceptions for SANs.  You may add them in your Artifact at creation time.

...

There are two varieties of templates that are designed to make creating certificates in today's more dynamic environment

Vanity URL:

Many services have Vanity URLs (or Round Robin). AAF is one of these. Normally, Certificate Manager validates whether the deployment call is made from the Artifact created. With the "Vanity URL Template", when deploying a new certificate, the check is made whether the incoming request for deployment is made from on of the machines in the Vanity URL, if so, then it is accepted, and a new Artifact is created for that machine is created in the Template Image for the particular machine requesting.

...

When Deploying, adding the "machine" on the command line is required in the format: <vanity URL>:<real machine name>[:<additional SAN>]* 

Domain:

The "Domain" is a special case, used strictly by Dynamic VM creators, and similar tools. In this case, the MechID owner specifies that his MechID may deployed on any in a specific domain, such as "*.vmgroup.onap.org". This approval requires special CSO exception as well as AAF approval, and when accepted, the permission "org.onap.aaf.ca|aaf|domain" is grant

...