DRAFT - THIS GUIDE IS A WORK IN PROGRESS

This documentation will help you to up and run AAF service from the docker image


Step 1:

-----------

git clone https://gerrit.onap.org/r/aaf/authz

Build

Note:  use ONAP maven repo settings.xml file


$ cd authz
$ mvn clean install -DskipTests


Note: we are working on Test cases and some of them are failing during build phase. Use ONAP maven repo settings.xml file 

Build Docker Image

$ cd authz-service
$ mvn clean install docker:build

Note: This process will create the authz-service docker image, and pull openjdk:8-jdk as part of the build

Step 2:

-----------

Make sure you have installed Docker & Docker Compose on your VM / Server ( Linux/Windows)

We have written a docker-compose file which will bind AAF service & Cassandra DB  and loads data to Cassandra DB.

Path to docker- compose folder

$ cd src/main/resources/docker-compose

Check  read & write permissions for docker-compose folder

$ chmod +x *.sh

To start AAF service use the following command. Which will up AAF & Cassandra docker instances.

$ docker-compose up -d

at this point AAF & Cassandra Images will be downloaded and containers will start and service will be up.

Note: ecomp.cql is the default data  template which will be loaded into Cassandra container. Which contains default namespaces,roles,permissions and APPID to test AAF service.

To check running containers 

$ docker ps

 

To check container logs with docker logs <container-name/ID>

For example, to use the container Id of the attos/aaf container in the screenshot above:

$ docker logs 91e6c35286b1

To access files inside the container

$ docker exec -it dockercompose_aaf_container_1 bash

AAF files are located in the following folder    : /opt

  • /opt/app/aaf/authz-service/2.0.15/etc
  • /opt/app/aaf/authz-service/2.0.15/lib


to find authz-service logs find them in the following folders:

 logs

_LOG_DIR_

 

Step 3:  access the cassandra command line from bash

---------------------------------------------------

docker exec -it dockercompose_cassandra_container_1 bash

1.cqlsh -u root -p root    

2.use authz;   ( to use keyspace)

3.describe tables;   ( to list all the tables)

3.select * from ns;     ( to check name spaces ,perm,roles etc)


To come out from bash & container

quit

exit


Step 4:  AAF Command line to  create & grant permissions

 ---------------------------------------------------

Get into the aaf container

1.docker exec -it dockercompose_aaf_container_1 bash

2.cd opt/app/aaf/authz-service/

3. sh runaafcli.sh –c

aaf_id :   dgl@openecomp.org

pass:        ecomp_admin


At this point you get access to AAF command line

aafcli> ns list name org.openecomp       

will give you the details of namespace org.openecomp


To get list of permission types of the user

>> perm list user dgl@openecomp.org


Create and grant permissions

>> perm create org.openecomp.dmaapBC.mr.topic :topic.org.openecomp.dmaapBC.mytopic1 pub org.openecomp.dmaapBC.admin org.openecomp.dmaapBC.access


>> perm create org.openecomp.dmaapBC.mr.topic :topic.org.openecomp.dmaapBC.mytopic1 sub org.openecomp.dmaapBC.admin org.openecomp.dmaapBC.access


AAF Command Line


AAF commands are broken into 4 major categories:

  • ns - commands dealing with a namespace
  • perm - commands dealing with permissions
  • role - commands dealing with roles
  • user - commands dealing with users

If you know you want to do something namespace related, type "ns" and hit return; you will be given a list of all the subcommands to "ns", along with the syntax of each.


Output of "Help"
AAF Command Line Tool
---------------------
  ------------------------------------------------------------------------------
  perm create <type> <instance> <action> [role[,role]* (to Grant to)]
       delete <type> <instance> <action>
       <grant|ungrant> <type> <instance> <action> <role[,role]*>
       rename <type> <instance> <action> <new type> <new instance> <new action>
       list user <name>
            name <root perm name>
            activity <type>
  ------------------------------------------------------------------------------
  role <create|delete> <name>
       user <add|del> <role> <id[,id]*>
       list user <id>
            name <role>
            activity <name>
  ------------------------------------------------------------------------------
  user role <add|del> <user> <role[,role]*>
       cred <add|del|reset> <id> [password (not required for del)]
       delegate <add|upd|del> <from> [to REQ A&U] [until (YYYY-MM-DD) REQ A]
       list role <role>
            perm <type> <instance> <action>
            delegates <user|delegate> <id>
            approvals <user|approver|ticket> <value>
            activity <user>
  ------------------------------------------------------------------------------
  ns create <name> <responsible (id[,id]*)> [admin (id[,id]*)]
     delete <name>
     admin <add|del> <name> <id[,id]*>
     responsible <add|del> <name> <id[,id]*>
     list name <ns>
          activity <name>
  ------------------------------------------------------------------------------


Detailed Help
AAF Command Line Tool

  ------------------------------------------------------------------------------
  perm create <type> <instance> <action> [role[,role]* (to Grant to)]
  ------------------------------------------------------------------------------
    Create a Permission with:
      type     - A Namespace qualified identifier identifying the kind of
                 resource to be protected
      instance - A name that distinguishes a particular instance of resource
      action   - What kind of action is allowed
      role(s)  - Perms granted to these Comma separated Role(s)
                 Nonexistent role(s) will be created, if in same namespace
        Note: Instance and Action can be a an '*' (enter \\* on Unix Shell)
      APIs:
        POST authz/perm application/PermRequest+json;version=2.0
  ------------------------------------------------------------------------------
  perm delete <type> <instance> <action>
  ------------------------------------------------------------------------------
    Delete a Permission with type,instance and action
        see Create for definitions
    APIs:
      DELETE authz/perm application/PermKey+json;version=2.0
  ------------------------------------------------------------------------------
  perm <grant|ungrant> <type> <instance> <action> <role[,role]*>
  ------------------------------------------------------------------------------
    Grant a Permission to a Role or Roles  OR
    Ungrant a Permission from a Role or Roles:
        see Create for definitions of type,instance and action
    APIs:
      POST authz/role/<role>/perm application/PermKey+json;version=2.0
      DELETE authz/role/<role>/perm application/PermKey+json;version=2.0
  ------------------------------------------------------------------------------
  perm rename <type> <instance> <action> <new type> <new instance> <new action>
  ------------------------------------------------------------------------------
    Rename a Permission from:
      <type> <instance> <action>
    to:
      <new type> <new instance> <new action>
    Namespace must be the same in <type> and <new type>
        see Create for definitions of type,instance and action
    APIs:
      PUT authz/perm/<type>/<instance>/<action> ...
            application/PermRequest+json;version=2.0
  ------------------------------------------------------------------------------
  perm list user <name>
  ------------------------------------------------------------------------------
    List Permissions by User
    APIs:
      GET authz/perms/user/<user id> application/Perms+json;version=2.0
  ------------------------------------------------------------------------------
  perm list name <root perm name>
  ------------------------------------------------------------------------------
    List Child Permissions
    APIs:
      GET authz/perms/<parent type> application/Perms+json;version=2.0
  ------------------------------------------------------------------------------
  perm list activity <type>
  ------------------------------------------------------------------------------
    List Activity of Permission
    APIs:
      GET authz/hist/perm/<type> application/History+json;version=2.0
  ------------------------------------------------------------------------------

  ------------------------------------------------------------------------------
  role <create|delete> <name>
  ------------------------------------------------------------------------------
    Create OR Delete a Role
      name - Name of Role to create
    APIs:
      POST authz/role application/RoleRequest+json;version=2.0
      DELETE authz/role application/RoleRequest+json;version=2.0
  ------------------------------------------------------------------------------
  role user <add|del> <role> <id[,id]*>
  ------------------------------------------------------------------------------
    Add OR Delete a User to/from a Role
      role  - Name of Role to create
      id(s) - ID or IDs to add to the Role
      Note: this is the same as "user role add..." except allows
      assignment of role to multiple userss
    APIs:
      POST authz/userRole application/UserRoleRequest+json;version=2.0
      DELETE authz/userRole/<user>/<role> application/Void+json;version=2.0
  ------------------------------------------------------------------------------
  role list user <id>
  ------------------------------------------------------------------------------
    List Roles for User
    APIs:
      GET authz/roles/user/<user> application/Roles+json;version=2.0
  ------------------------------------------------------------------------------
  role list name <role>
  ------------------------------------------------------------------------------
    List Roles for Role
    APIs:
      GET authz/roles/<role> application/Roles+json;version=2.0
  ------------------------------------------------------------------------------
  role list activity <name>
  ------------------------------------------------------------------------------
    List Activity of Role
    APIs:
      GET authz/hist/role/<role> application/History+json;version=2.0
  ------------------------------------------------------------------------------

  ------------------------------------------------------------------------------
  user role <add|del> <user> <role[,role]*>
  ------------------------------------------------------------------------------
    Add OR Delete a User to/from a Role
      user    - ID of User
      role(s) - Role or Roles to which to add the User
      Note: this is the same as "role user add..." except allows
      assignment of user to multiple roles
    APIs:
      POST authz/userRole application/UserRoleRequest+json;version=2.0
      DELETE authz/userRole/<user>/<role> application/Void+json;version=2.0
  ------------------------------------------------------------------------------
  user cred <add|del|reset> <id> [password (not required for del)]
  ------------------------------------------------------------------------------
    Add, Delete or Reset Credential
      id       - the ID to create/delete/reset within AAF
      password - Company Policy compliant Password (not required for Delete)
      The Domain can be related to any Namespace you have access to *
      The Domain is in reverse order of Namespace, i.e.
        NS of com.att.myapp can create user of XY1234@myapp.att.com
      *NOTE: com.att.csp is a reserved Domain for Global Sign On
      Delegates can be listed by the User or by the Delegate
    APIs:
      POST authn/cred application/CredRequest+json;version=2.0
      DELETE authn/cred application/CredRequest+json;version=2.0
      PUT authn/cred application/CredRequest+json;version=2.0
  ------------------------------------------------------------------------------
  user delegate <add|upd|del> <from> [to REQ A&U] [until (YYYY-MM-DD) REQ A]
  ------------------------------------------------------------------------------
    Add, Update or Delete Delegate
      A Delegate is a person who will temporarily cover the Approval and
      Ownership questions on behalf of the person Responsible.
      fromID - the person who is the Responsible person of record
      toID   - the person who will be delegated (required for Add/Update)
      until  - the end date for this delegation
    APIs:
      POST /authz/delegate application/DelgRequest+json;version=2.0
      DELETE /authz/delegate application/DelgRequest+json;version=2.0
      PUT /authz/delegate application/DelgRequest+json;version=2.0
  ------------------------------------------------------------------------------
  user list role <role>
  ------------------------------------------------------------------------------
    List Users for Role
      This report lists the users associated to Roles.
      role - the Role name
    APIs:
      GET authz/users/role/<role> application/Users+json;version=2.0
  ------------------------------------------------------------------------------
  user list perm <type> <instance> <action>
  ------------------------------------------------------------------------------
    List Users for Permission
      This report lists the users associated to Permissions.  Since Users
      are associated to Roles, and Roles have Permissions, this report
      accomodates all these linkages.
      The URL must contain the Permission's type,instance and action, and
      may include "*"s (type in as \\*).
      See Perm Create Documentation for definitions.
    APIs:
      GET authz/users/perm/<type>/<instance>/<action> ...
            application/Users+json;version=2.0
  ------------------------------------------------------------------------------
  user list delegates <user|delegate> <id>
  ------------------------------------------------------------------------------
    List Delegates
      Delegates are those people temporarily assigned to cover the
      responsibility of Approving, etc, while the actual Responsible
      Party is absent.  Typically, this is for Vacation, or Business
      Travel.
      Delegates can be listed by the User or by the Delegate
    APIs:
      GET authz/delegates/user/<id> application/Delgs+json;version=2.0
      GET authz/delegates/delegate/<id> application/Delgs+json;version=2.0
  ------------------------------------------------------------------------------
  user list approvals <user|approver|ticket> <value>
  ------------------------------------------------------------------------------
    List Approvals
      Approvals are used when the Requestor does not have the rights
      to perform the action required.  Approvers are those listed as
      responsible for Namespace associated with the request, and those
      required by the Company by Policy.  This may be, for instance
      the supervisor of the requestor
      Delegates can be listed by User, Approver or Ticket.
    APIs:
      GET authz/approval/user/<value> application/Approvals+json;version=2.0
      GET authz/approval/approver/<value> application/Approvals+json;version=2.0
      GET authz/approval/ticket/<value> application/Approvals+json;version=2.0
  ------------------------------------------------------------------------------
  user list activity <user>
  ------------------------------------------------------------------------------
    List Activity of User
    APIs:
      GET authz/hist/user/<user> application/History+json;version=2.0
  ------------------------------------------------------------------------------

  ------------------------------------------------------------------------------
  ns create <name> <responsible (id[,id]*)> [admin (id[,id]*)]
  ------------------------------------------------------------------------------
    Create a Namespace
      name        - Namespaces are dot-delimited, ex com.att.myapp
                    and must be created with parent credentials.
                    Ex: to create com.att.myapp, you must be admin for com.att
                    or com
      responsible - This is the person(s) who receives Notifications and
                    approves Requests regarding this Namespace. Companies have
                    Policies as to who may take on this responsibility
      admin       - These are the people who are allowed to make changes on
                    the Namespace, including creating Roles, Permissions
                    and Credentials
    APIs:
      POST authz/ns application/NsRequest+json;version=2.0
  ------------------------------------------------------------------------------
  ns delete <name>
  ------------------------------------------------------------------------------
    Delete a Namespace
        Namespaces cannot normally be deleted when there are still credentials
        associated with them. These can be deleted automatically by setting
        "force" property.  i.e. set force=true  (note force is unset after
        first use)
        Permissions and Roles are not deleted when the Namespace is. Roles and
        Permissions are retained, but assigned to the Parent Namespace.
        Similarly, Namespaces can be created even though there are Roles/Perms
        with that name.  They are simply reassigned to the Child Namespace
    APIs:
      DELETE authz/ns/<ns>[?force=true] application/Void+json;version=2.0
  ------------------------------------------------------------------------------
  ns admin <add|del> <name> <id[,id]*>
  ------------------------------------------------------------------------------
    Add or Delete Administrator to/from Namespace
        name - Name of Namespace
        id   - Credential of Person(s) to be Administrator
        aafcli will call API on each ID presented.
    APIs:
      POST authz/ns/<ns>/admin/<id> application/Void+json;version=2.0
      DELETE authz/ns/<ns>/admin/<id> application/Void+json;version=2.0
  ------------------------------------------------------------------------------
  ns responsible <add|del> <name> <id[,id]*>
  ------------------------------------------------------------------------------
    Add or Delete Responsible person to/from Namespace
      Responsible persons receive Notifications and approve Requests
      regarding this Namespace. Companies have Policies as to who may
      take on this responsibility
        name - Name of Namespace
        id   - Credential of Person(s) to be made responsible
        aafcli will call API on each ID presented.
    APIs:
      POST authz/ns/<ns>/responsible/<id> application/Void+json;version=2.0
      DELETE authz/ns/<ns>/responsible/<id> application/Void+json;version=2.0
  ------------------------------------------------------------------------------
  ns list name <ns>
  ------------------------------------------------------------------------------
    List Namespaces by Name
    APIs:
      GET authz/nss/<ns> application/Nss+json;version=2.0
    Indirectly uses:
      GET authz/roles/ns/<ns> application/Roles+json;version=2.0
      GET authz/perms/ns/<ns> application/Perms+json;version=2.0
  ------------------------------------------------------------------------------
  ns list activity <name>
  ------------------------------------------------------------------------------
    List Activity of Namespace
    APIs:
      GET authz/hist/ns/<ns> application/History+json;version=2.0
  ------------------------------------------------------------------------------

  ------------------------------------------------------------------------------




3 Comments

  1. Does it install Certificate manager too?

    Could you give some example on using CADI to send certificate request and get the certificate from CA?

    Srini


  2. Hi,


    I'm aware that it's a draft version, but it's not valid  after I believe around 15.03.2018, when the structure of the project started changing due to work on CSM I believe. I can't build docker image using maven nor using provided bash scripts, and it is hard to guess what's missing.

    Would you update the information soon? Is it possible currently to build and run AAF locally ?

  3. Anyone know a valid mapping between "authz-service" files and the current file structure?