docs/user-guide.rst

   1 .. _aaa-user-guide:
   2
   3 Authentication, Authorization and Accounting (AAA) Services - User guide
   4 ========================================================================
   5
   6 Overview
   7 --------
   8
   9 Authentication, Authorization and Accounting (AAA) is a term for a
  10 framework controlling access to resources, enforcing policies to use
  11 those resources and auditing their usage. These processes are the
  12 fundamental building blocks for effective network management and security.
  13
  14 Authentication provides a way of identifying a user, typically by
  15 having the user enter a valid user name and valid password before access
  16 is granted. The process of authentication is based on each user having a unique
  17 set of criteria for gaining access. The AAA framework compares a user's
  18 authentication credentials with other user credentials stored in a database.
  19 If the credentials match, the user is granted access to the network.
  20 If the credentials don't match, authentication fails and access is denied.
  21
  22 Authorization is the process of finding out what an authenticated user is
  23 allowed to do within the system, which tasks can do, which API can call, etc.
  24 The authorization process determines whether the user has the authority
  25 to perform such actions.
  26
  27 Accounting is the process of logging the activity of an authenticated user,
  28 for example, the amount of data a user has sent and/or received during a
  29 session, which APIs called, etc.
  30
  31 Terms And Definitions
  32 ^^^^^^^^^^^^^^^^^^^^^
  33
  34 AAA
  35     Authentication, Authorization and Accounting.
  36
  37 Token
  38     A claim of access to a group of resources on the controller.
  39
  40 Domain
  41     A group of resources, direct or indirect, physical, logical, or
  42     virtual, for the purpose of access control.
  43
  44 User
  45     A person who either owns or has access to a resource or group of
  46     resources on the controller.
  47
  48 Role
  49     Opaque representation of a set of permissions, which is merely a
  50     unique string as admin or guest.
  51
  52 Credential
  53     Proof of identity such as user name and password, OTP, biometrics, or
  54     others.
  55
  56 Client
  57     A service or application that requires access to the controller.
  58
  59 Claim
  60     A data set of validated assertions regarding a user, e.g. the role,
  61     domain, name, etc.
  62
  63 Grant
  64     It is the entity associating a user with his role and domain.
  65
  66 IdP
  67     Identity Provider.
  68
  69 TLS
  70     Transport Layer Security
  71
  72 CLI
  73     Command Line Interface
  74
  75 Security Framework for AAA services
  76 -----------------------------------
  77
  78 Since Boron release, the OpenDaylight's AAA services are based on the
  79 `Apache Shiro <https://shiro.apache.org/>`_ Java Security Framework. The main
  80 configuration file for AAA is located at “etc/shiro.ini” relative to the
  81 OpenDaylight Karaf home directory.
  82
  83
  84 How to enable AAA
  85 -----------------
  86
  87 AAA is enabled through installing the odl-aaa-shiro feature. The vast majority
  88 of OpenDaylight's northbound APIs (and all RESTCONF APIs) are protected by AAA
  89 by default when installing the +odl-restconf+ feature, since the odl-aaa-shiro
  90 is automatically installed as part of them. In the cases that APIs are *not*
  91 protected by AAA, this will be noted in the per-project release notes.
  92
  93 How to disable AAA
  94 ------------------
  95
  96 Edit the “etc/opendaylight/datastore/initial/config/aaa-app-config.xml” file and replace the following:
  97
  98 ::
  99
 100     /** = authcBasic
 101
 102 with
 103
 104 ::
 105
 106     /** = anon
 107
 108 Then restart the Karaf process.
 109
 110 AAA Realms
 111 ----------
 112
 113 AAA plugin utilizes the Shiro Realms to support pluggable authentication &
 114 authorization schemes. There are two parent types of realms:
 115
 116 -  AuthenticatingRealm
 117
 118    -  Provides no Authorization capability.
 119
 120    -  Users authenticated through this type of realm are treated
 121       equally.
 122
 123 -  AuthorizingRealm
 124
 125    -  AuthorizingRealm is a more sophisticated AuthenticatingRealm,
 126       which provides the additional mechanisms to distinguish users
 127       based on roles.
 128
 129    -  Useful for applications in which roles determine allowed
 130       capabilities.
 131
 132 OpenDaylight contains five implementations:
 133
 134 -  TokenAuthRealm
 135
 136    -  An AuthorizingRealm built to bridge the Shiro-based AAA service
 137       with the h2-based AAA implementation.
 138
 139    -  Exposes a RESTful web service to manipulate IdM policy on a
 140       per-node basis. If identical AAA policy is desired across a
 141       cluster, the backing data store must be synchronized using an out
 142       of band method.
 143
 144    -  A python script located at “etc/idmtool” is included to help
 145       manipulate data contained in the TokenAuthRealm.
 146
 147    -  Enabled out of the box. This is the realm configured by default.
 148
 149 -  ODLJndiLdapRealm
 150
 151    -  An AuthorizingRealm built to extract identity information from IdM
 152       data contained on an LDAP server.
 153
 154    -  Extracts group information from LDAP, which is translated into
 155       OpenDaylight roles.
 156
 157    -  Useful when federating against an existing LDAP server, in which
 158       only certain types of users should have certain access privileges.
 159
 160    -  Disabled out of the box.
 161
 162 -  ODLJndiLdapRealmAuthNOnly
 163
 164    -  The same as ODLJndiLdapRealm, except without role extraction.
 165       Thus, all LDAP users have equal authentication and authorization
 166       rights.
 167
 168    -  Disabled out of the box.
 169
 170 -  ODLActiveDirectoryRealm
 171
 172    - Wraps the generic ActiveDirectoryRealm provided by Shiro. This allows for
 173      enhanced logging as well as isolation of all realms in a single package,
 174      which enables easier import by consuming servlets.
 175
 176 -  KeystoneAuthRealm
 177
 178    - This realm authenticates OpenDaylight users against the OpenStack’s
 179      Keystone server.
 180
 181    - Disabled out of the box.
 182
 183 .. note::
 184
 185     More than one Realm implementation can be specified. Realms are attempted
 186     in order until authentication succeeds or all realm sources are exhausted.
 187     Edit the **securityManager.realms = $tokenAuthRealm** property in shiro.ini
 188     and add all the realms needed separated by commas.
 189
 190 TokenAuthRealm
 191 ^^^^^^^^^^^^^^
 192
 193 How it works
 194 ~~~~~~~~~~~~
 195
 196 The TokenAuthRealm is the default Authorization Realm deployed in OpenDaylight.
 197 TokenAuthRealm uses a direct authentication mechanism as shown in the following
 198 picture:
 199
 200 .. figure:: ./images/aaa/direct-authentication.png
 201    :alt: TokenAuthRealm direct authentication mechanism
 202
 203    TokenAuthRealm direct authentication mechanism
 204
 205 A user presents some credentials (e.g., username/password) directly to the
 206 OpenDaylight controller token endpoint /oauth2/token and receives an access
 207 token, which then can be used to access protected resources on the controller.
 208
 209 Configuring TokenAuthRealm
 210 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 211
 212 The TokenAuthRealm stores IdM data in an h2 database on each node. Thus,
 213 configuration of a cluster currently requires configuring the desired IdM policy
 214 on each node. There are two supported methods to manipulate the TokenAuthRealm
 215 IdM configuration:
 216
 217 -  idmtool configuration tool
 218
 219 -  RESTful Web Service configuration
 220
 221 **Idmtool**
 222 ###########
 223
 224 A utility script located at “karaf/target/assembly/bin/idmtool” is used to manipulate the
 225 TokenAuthRealm IdM policy. idmtool assumes a single domain, the default one
 226 (sdn), since multiple domains are not supported in the Boron release. General
 227 usage information for idmtool is derived through issuing the following command:
 228
 229 ::
 230
 231     $ python3 idmtool -h
 232     usage: idmtool [-h] [--target-host TARGET_HOST] [-k]
 233                    user
 234                    {list-users,add-user,change-password,delete-user,list-domains,list-roles,add-role,delete-role,add-grant,get-grants,delete-grant,
 235     change-jolokia-password}
 236                    ...
 237
 238     positional arguments:
 239       user                  username for ODL node
 240       {list-users,add-user,change-password,delete-user,list-domains,list-roles,add-role,delete-role,add-grant,get-grants,delete-grant,
 241     change-jolokia-password}
 242                             sub-command help
 243         list-users          list all users
 244         add-user            add a user
 245         change-password     change a password
 246         delete-user         delete a user
 247         list-domains        list all domains
 248         list-roles          list all roles
 249         add-role            add a role
 250         delete-role         delete a role
 251         add-grant           add a grant
 252         get-grants          get grants for userid on sdn
 253         delete-grant        delete a grant
 254         change-jolokia-password
 255                             change the jolokia specific password
 256
 257     optional arguments:
 258       -h, --help            show this help message and exit
 259       --target-host TARGET_HOST
 260                             target host url in form protocol://host:port
 261       -k, --insecure        disable HTTPS certificate verification
 262
 263
 264 Add a user
 265 ''''''''''
 266
 267 ::
 268
 269     python3 idmtool admin add-user newUser
 270     Password:    (default "admin")
 271     Enter new password:
 272     Re-enter password:
 273     add_user(admin)
 274
 275     Operation Successful!!
 276     json:
 277     {
 278         "description": "",
 279         "domainid": "sdn",
 280         "email": "",
 281         "enabled": 1,
 282         "name": "newUser",
 283         "password": "**********",
 284         "salt": "**********",
 285         "userid": "newUser@sdn"
 286     }
 287
 288 .. note::
 289
 290     AAA redacts the password and salt fields for security purposes.
 291
 292 Delete a user
 293 '''''''''''''
 294
 295 ::
 296
 297     $ python3 idmtool admin delete-user newUser@sdn
 298     Password:
 299     delete_user(newUser@sdn)
 300
 301     Operation Successful!!
 302
 303 List all users
 304 ''''''''''''''
 305
 306 ::
 307
 308     $ python3 idmtool admin list-users
 309     Password:
 310     list_users
 311     http://localhost:8181/auth/v1/users
 312
 313     Operation Successful!!
 314     json:
 315     {
 316         "users": [
 317             {
 318                 "description": "admin user",
 319                 "domainid": "sdn",
 320                 "email": "",
 321                 "enabled": 1,
 322                 "name": "admin",
 323                 "password": "**********",
 324                 "salt": "**********",
 325                 "userid": "admin@sdn"
 326             }
 327         ]
 328     }
 329
 330 Change a user’s password
 331 ''''''''''''''''''''''''
 332
 333 ::
 334
 335     $ python3 idmtool admin change-password admin@sdn
 336     Password:
 337     Enter new password:
 338     Re-enter password:
 339     change_password(admin)
 340
 341     Operation Successful!!
 342     json:
 343     {
 344         "description": "admin user",
 345         "domainid": "sdn",
 346         "email": "",
 347         "enabled": 1,
 348         "name": "admin",
 349         "password": "**********",
 350         "salt": "**********",
 351         "userid": "admin@sdn"
 352     }
 353
 354 Add a role
 355 ''''''''''
 356
 357 ::
 358
 359     $ python3 idmtool admin add-role network-admin
 360     Password:
 361     add_role(network-admin)
 362
 363     Operation Successful!!
 364     json:
 365     {
 366         "description": "",
 367         "domainid": "sdn",
 368         "name": "network-admin",
 369         "roleid": "network-admin@sdn"
 370     }
 371
 372 Delete a role
 373 '''''''''''''
 374
 375 ::
 376
 377     $ python3 idmtool admin delete-role network-admin@sdn
 378     Password:
 379     delete_role(network-admin@sdn)
 380
 381     Operation Successful!!
 382
 383 List all roles
 384 ''''''''''''''
 385
 386 ::
 387
 388     $ python3 idmtool admin list-roles
 389     Password:
 390     list_roles
 391     http://localhost:8181/auth/v1/roles
 392
 393     Operation Successful!!
 394     json:
 395     {
 396         "roles": [
 397             {
 398                 "description": "a role for admins",
 399                 "domainid": "sdn",
 400                 "name": "admin",
 401                 "roleid": "admin@sdn"
 402             },
 403             {
 404                 "description": "a role for users",
 405                 "domainid": "sdn",
 406                 "name": "user",
 407                 "roleid": "user@sdn"
 408             }
 409         ]
 410     }
 411
 412 List all domains
 413 ''''''''''''''''
 414
 415 ::
 416
 417     $ python3 idmtool admin list-domains
 418     Password:
 419     list_domains
 420     http://localhost:8181/auth/v1/domains
 421
 422     Operation Successful!!
 423     json:
 424     {
 425         "domains": [
 426             {
 427                 "description": "default odl sdn domain",
 428                 "domainid": "sdn",
 429                 "enabled": true,
 430                 "name": "sdn"
 431             }
 432         ]
 433     }
 434
 435 Add a grant
 436 '''''''''''
 437
 438 ::
 439
 440     $ python3 idmtool admin add-grant newUser@sdn admin@sdn
 441     Password:
 442     add_grant(userid=newUser@sdn,roleid=admin@sdn)
 443
 444     Operation Successful!!
 445     json:
 446     {
 447         "domainid": "sdn",
 448         "grantid": "newUser@sdn@admin@sdn@sdn",
 449         "roleid": "admin@sdn",
 450         "userid": "newUser@sdn"
 451     }
 452
 453 Delete a grant
 454 ''''''''''''''
 455
 456 ::
 457
 458     $ python3 idmtool admin delete-grant newUser@sdn admin@sdn
 459     Password:
 460     http://localhost:8181/auth/v1/domains/sdn/users/newUser@sdn/roles/admin@sdn
 461     delete_grant(userid=newUser@sdn,roleid=admin@sdn)
 462
 463     Operation Successful!!
 464
 465 Get grants for a user
 466 '''''''''''''''''''''
 467
 468 ::
 469
 470     python3 idmtool admin get-grants admin@sdn
 471     Password:
 472     get_grants(admin@sdn)
 473     http://localhost:8181/auth/v1/domains/sdn/users/admin@sdn/roles
 474
 475     Operation Successful!!
 476     json:
 477     {
 478         "roles": [
 479             {
 480                 "description": "a role for users",
 481                 "domainid": "sdn",
 482                 "name": "user",
 483                 "roleid": "user@sdn"
 484             },
 485             {
 486                 "description": "a role for admins",
 487                 "domainid": "sdn",
 488                 "name": "admin",
 489                 "roleid": "admin@sdn"
 490             }
 491         ]
 492     }
 493
 494 **Configuration using the RESTful Web Service**
 495 ###############################################
 496
 497 The TokenAuthRealm IdM policy is fully configurable through a RESTful
 498 web service. Few examples are included in this guide:
 499
 500 Get all users
 501 '''''''''''''
 502
 503 ::
 504
 505     curl --request GET 'http://localhost:8181/auth/v1/users' --header 'Authorization: Basic YWRtaW46YWRtaW4='
 506     OUTPUT:
 507     {
 508         "users": [
 509             {
 510                 "userid": "admin@sdn",
 511                 "name": "admin",
 512                 "description": "admin user",
 513                 "enabled": 1,
 514                 "email": "",
 515                 "password": "**********",
 516                 "salt": "**********",
 517                 "domainid": "sdn"
 518             }
 519         ]
 520     }
 521
 522 Create a user
 523 '''''''''''''
 524
 525 ::
 526
 527     curl --request POST 'http://localhost:8181/auth/v1/users' \
 528     --header 'Authorization: Basic YWRtaW46YWRtaW4=' \
 529     --header 'Content-Type: application/json' \
 530     --data-raw '    {
 531             "name": "ryan",
 532             "password": "ryan",
 533             "domainid": "sdn",
 534             "description": "Ryan'\''s User Account",
 535             "email": "ryandgoulding@gmail.com"
 536         }'
 537
 538     OUTPUT:
 539     {
 540         "userid": "ryan@sdn",
 541         "name": "ryan",
 542         "description": "Ryan's User Account",
 543         "enabled": 1,
 544         "email": "ryandgoulding@gmail.com",
 545         "password": "**********",
 546         "salt": "**********",
 547         "domainid": "sdn"
 548     }
 549
 550 Get grants for the new 'ryan' user
 551 ''''''''''''''''''''''''''''''''''
 552
 553 ::
 554
 555     curl --request GET 'http://localhost:8181/auth/v1/domains/sdn/users/ryan@sdn/roles' \
 556     --header 'Authorization: Basic YWRtaW46YWRtaW4='
 557
 558     OUTPUT:
 559     {
 560         "roles": []
 561     }
 562
 563 Add admin grants for the 'ryan' user
 564 ''''''''''''''''''''''''''''''''''''
 565
 566 ::
 567
 568     curl --request POST 'http://localhost:8181/auth/v1/domains/sdn/users/ryan@sdn/roles' \
 569     --header 'Authorization: Basic YWRtaW46YWRtaW4=' \
 570     --header 'Content-Type: application/json' \
 571     --data-raw '{
 572         "roleid": "admin@sdn",
 573         "name": "admin",
 574         "description": "a role for admins",
 575         "domainid": "sdn"
 576     }'
 577
 578     OUTPUT:
 579     {
 580         "grantid": "ryan@sdn@admin@sdn@sdn",
 581         "domainid": "sdn",
 582         "userid": "ryan@sdn",
 583         "roleid": "admin@sdn"
 584     }
 585
 586 Remove admin grants for the 'ryan' user
 587 '''''''''''''''''''''''''''''''''''''''
 588
 589 ::
 590
 591     curl --request DELETE 'http://localhost:8181/auth/v1/domains/sdn/users/ryan@sdn/roles/admin@sdn' \
 592     --header 'Authorization: Basic YWRtaW46YWRtaW4='
 593
 594     OUTPUT: 204
 595
 596 Get all domains
 597 '''''''''''''''
 598
 599 ::
 600
 601     curl --request GET 'http://localhost:8181/auth/v1/domains' --header 'Authorization: Basic YWRtaW46YWRtaW4='
 602
 603     OUTPUT:
 604     {
 605         "domains": [
 606             {
 607                 "domainid": "sdn",
 608                 "name": "sdn",
 609                 "description": "default odl sdn domain",
 610                 "enabled": true
 611             }
 612         ]
 613     }
 614
 615 Create a new 'test' domain
 616 ''''''''''''''''''''''''''
 617
 618 ::
 619
 620     curl --request POST 'http://localhost:8181/auth/v1/domains' \
 621     --header 'Authorization: Basic YWRtaW46YWRtaW4=' \
 622     --header 'Content-Type: application/json' \
 623     --data-raw '{
 624         "name": "test",
 625         "description": "Odl test domain",
 626         "enabled": true
 627     }'
 628
 629     OUTPUT:
 630     {
 631         "domainid": "test",
 632         "name": "test",
 633         "description": "Odl test domain",
 634         "enabled": true
 635     }
 636
 637 Create an OAuth2 Token For Admin Scoped to SDN
 638 ''''''''''''''''''''''''''''''''''''''''''''''
 639
 640 ::
 641
 642     curl -d 'grant_type=password&username=admin&password=a&scope=sdn' http://localhost:8181/oauth2/token
 643
 644     OUTPUT:
 645     {
 646         "expires_in":3600,
 647         "token_type":"Bearer",
 648         "access_token":"5a615fbc-bcad-3759-95f4-ad97e831c730"
 649     }
 650
 651 Use an OAuth2 Token
 652 '''''''''''''''''''
 653
 654 ::
 655
 656     curl -H "Authorization: Bearer 5a615fbc-bcad-3759-95f4-ad97e831c730" http://localhost:8181/auth/v1/domains
 657     {
 658         "domains":
 659         [
 660             {
 661                 "domainid":"sdn",
 662                 "name":"sdn”,
 663                 "description":"default odl sdn domain",
 664                 "enabled":true
 665             }
 666         ]
 667     }
 668
 669 **Token Store Configuration Parameters**
 670 ########################################
 671
 672 Edit the file “etc/opendaylight/karaf/08-authn-config.xml” and edit the
 673 following: .\ **timeToLive**: Configure the maximum time, in milliseconds,
 674 that tokens are to be cached. Default is 360000. Save the file.
 675
 676 ODLJndiLdapRealm
 677 ^^^^^^^^^^^^^^^^
 678
 679 How it works
 680 ~~~~~~~~~~~~
 681
 682 LDAP integration is provided in order to externalize identity
 683 management. This configuration allows federation with an external LDAP server.
 684 The user’s OpenDaylight role parameters are mapped to corresponding LDAP
 685 attributes as specified by the groupRolesMap. Thus, an LDAP operator can
 686 provision attributes for LDAP users that support different OpenDaylight role
 687 structures.
 688
 689 Configuring ODLJndiLdapRealm
 690 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 691
 692 To configure LDAP parameters, modify "etc/shiro.ini"
 693 parameters to include the ODLJndiLdapRealm:
 694
 695 ::
 696
 697     # OpenDaylight provides a few LDAP implementations, which are disabled out of the box.
 698     # ODLJndiLdapRealm includes authorization functionality based on LDAP elements
 699     # extracted through and LDAP search.  This requires a bit of knowledge about
 700     # how your LDAP system is setup.  An example is provided below:
 701     ldapRealm = org.opendaylight.aaa.shiro.realm.ODLJndiLdapRealm
 702     ldapRealm.userDnTemplate = uid={0},ou=People,dc=DOMAIN,dc=TLD
 703     ldapRealm.contextFactory.url = ldap://<URL>:389
 704     ldapRealm.searchBase = dc=DOMAIN,dc=TLD
 705     ldapRealm.ldapAttributeForComparison = objectClass
 706     ldapRealm.groupRolesMap = "Person":"admin"
 707     # ...
 708     # further down in the file...
 709     # Stacked realm configuration;  realms are round-robbined until authentication succeeds or realm sources are exhausted.
 710     securityManager.realms = $tokenAuthRealm, $ldapRealm
 711
 712 ODLJndiLdapRealmAuthNOnly
 713 ^^^^^^^^^^^^^^^^^^^^^^^^^
 714
 715 How it works
 716 ~~~~~~~~~~~~
 717
 718 This is useful for setups where all LDAP users are allowed equal access.
 719
 720 Configuring ODLJndiLdapRealmAuthNOnly
 721 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 722
 723 Edit the "etc/shiro.ini" file and modify the following:
 724
 725 ::
 726
 727     ldapRealm = org.opendaylight.aaa.shiro.realm.ODLJndiLdapRealm
 728     ldapRealm.userDnTemplate = uid={0},ou=People,dc=DOMAIN,dc=TLD
 729     ldapRealm.contextFactory.url = ldap://<URL>:389
 730     # ...
 731     # further down in the file...
 732     # Stacked realm configuration;  realms are round-robbined until authentication succeeds or realm sources are exhausted.
 733     securityManager.realms = $tokenAuthRealm, $ldapRealm
 734
 735 KeystoneAuthRealm
 736 ^^^^^^^^^^^^^^^^^
 737
 738 How it works
 739 ~~~~~~~~~~~~
 740
 741 This realm authenticates OpenDaylight users against the OpenStack's Keystone
 742 server. This realm uses the
 743 `Keystone's Identity API v3 <https://developer.openstack.org/api-ref/identity/v3/>`_
 744 or later.
 745
 746 .. figure:: ./images/aaa/keystonerealm-authentication.png
 747    :alt: KeystoneAuthRealm authentication mechanism
 748
 749    KeystoneAuthRealm authentication/authorization mechanism
 750
 751 As can shown on the above diagram, once configured, all the RESTCONF APIs calls
 752 will require sending **user**, **password** and optionally **domain** (1). Those
 753 credentials are used to authenticate the call against the Keystone server (2) and,
 754 if the authentication succeeds, the call will proceed to the MDSAL (3). The
 755 credentials must be provisioned in advance within the Keystone Server. The user
 756 and password are mandatory, while the domain is optional, in case it is not
 757 provided within the REST call, the realm will default to (**Default**),
 758 which is hard-coded. The default domain can be also configured through the
 759 *shiro.ini* file (see the :doc:`AAA User Guide <user-guide>`).
 760
 761 The protocol between the Controller and the Keystone Server (2) can be either
 762 HTTPS or HTTP. In order to use HTTPS the Keystone Server's certificate
 763 must be exported and imported on the Controller (see the :ref:`Certificate Management <certificate-management>` section).
 764
 765 Configuring KeystoneAuthRealm
 766 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 767
 768 Edit the "etc/shiro.ini" file and modify the following:
 769
 770 ::
 771
 772     # The KeystoneAuthRealm allows for authentication/authorization against an
 773     # OpenStack's Keystone server. It uses the Identity's API v3 or later.
 774     keystoneAuthRealm = org.opendaylight.aaa.shiro.realm.KeystoneAuthRealm
 775     # The URL where the Keystone server exposes the Identity's API v3 the URL
 776     # can be either HTTP or HTTPS and it is mandatory for this realm.
 777     keystoneAuthRealm.url = https://<host>:<port>
 778     # Optional parameter to make the realm verify the certificates in case of HTTPS
 779     #keystoneAuthRealm.sslVerification = true
 780     # Optional parameter to set up a default domain for requests using credentials
 781     # without domain, uncomment in case you want a different value from the hard-coded
 782     # one "Default"
 783     #keystoneAuthRealm.defaultDomain = Default
 784
 785 Once configured the realm, the mandatory fields are the fully quallified name of
 786 the class implementing the realm *keystoneAuthRealm* and the endpoint where the
 787 Keystone Server is listening *keystoneAuthRealm.url*.
 788
 789 The optional parameter *keystoneAuthRealm.sslVerification* specifies whether the
 790 realm has to verify the SSL certificate or not. The optional parameter
 791 *keystoneAuthRealm.defaultDomain* allows to use a different default domain from
 792 the hard-coded one *"Default"*.
 793
 794 Authorization Configuration
 795 ---------------------------
 796
 797 OpenDaylight supports two authorization engines at present, both of which are
 798 roughly similar in behavior:
 799
 800 - Shiro-Based Authorization
 801
 802 - MDSAL-Based Dynamic Authorization
 803
 804 .. note::
 805
 806     The preferred mechanism for configuring AAA Authentication is the
 807     MDSAL-Based Dynamic Authorization. Read the following section.
 808
 809 Shiro-Based Static Authorization
 810 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 811
 812 OpenDaylight AAA has support for Role Based Access Control (RBAC) based
 813 on the Apache Shiro permissions system. Configuration of the authorization
 814 system is done off-line; authorization currently cannot be configured
 815 after the controller is started. The Authorization provided by this mechanism
 816 is aimed towards supporting coarse-grained security policies, the MDSAL-Based
 817 mechanism allows for a more robust configuration capabilities. `Shiro-based
 818 Authorization <http://shiro.apache.org/web.html#Web-%7B%7B%5Curls%5C%7D%7D>`_
 819 describes how to configure the Authentication feature in detail.
 820
 821 .. note::
 822
 823     The Shiro-Based Authorization that uses the *shiro.ini* URLs section to
 824     define roles requirements is **deprecated** and **discouraged** since the
 825     changes made to the file are only honored on a controller restart.
 826
 827     Shiro-Based Authorization is not **cluster-aware**, so the changes made on
 828     the *shiro.ini* file have to be replicated on every controller instance
 829     belonging to the cluster.
 830
 831     The URL patterns are matched relative to the Servlet context leaving room
 832     for ambiguity, since many endpoints may match (i.e., "/restconf/modules" and
 833     "/auth/modules" would both match a "/modules/\**" rule).
 834
 835 Enable “admin” Role Based Access to the IdMLight RESTful web service
 836 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 837
 838 Edit the “etc/shiro.ini” configuration file and add “/auth/v1/\**=
 839 authcBasic, roles[admin]” above the line “/\** = authcBasic” within the
 840 “urls” section.
 841
 842 ::
 843
 844     /auth/v1/** = authcBasic, roles[admin]
 845     /** = authcBasic
 846
 847 This will restrict the idmlight rest endpoints so that a grant for admin
 848 role must be present for the requesting user.
 849
 850 .. note::
 851
 852     The ordering of the authorization rules above is important!
 853
 854 MDSAL-Based Dynamic Authorization
 855 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 856 The MDSAL-Based Dynamic authorization uses the MDSALDynamicAuthorizationFilter
 857 engine to restrict access to particular URL endpoint patterns. Users may define
 858 a list of policies that are insertion-ordered. Order matters for that list of
 859 policies, since the first matching policy is applied. This choice was made to
 860 emulate behavior of the Shiro-Based Authorization mechanism.
 861
 862 A **policy** is a key/value pair, where the key is a **resource**
 863 (i.e., a "URL pattern") and the value is a list of **permissions** for the
 864 resource. The following describes the various elements of a policy:
 865
 866 - **Resource**: the resource is a string URL pattern as outlined by
 867   Apache Shiro. For more information, see http://shiro.apache.org/web.html.
 868
 869 - **Description**: an optional description of the URL endpoint and why it is
 870   being secured.
 871
 872 - **Permissions list**: a list of permissions for a particular policy. If more
 873   than one permission exists in the permissions list they are evaluated using
 874   logical "OR". A permission describes the prerequisites to perform HTTP
 875   operations on a particular endpoint. The following describes the various
 876   elements of a permission:
 877
 878   + **Role**: the role required to access the target URL endpoint.
 879   + **Actions list**: a leaf-list of HTTP permissions that are allowed for a
 880     Subject possessing the required role.
 881
 882 This an example on how to limit access to the modules endpoint:
 883
 884 ::
 885
 886     HTTP Operation:
 887     put URL: /rests/data/aaa:http-authorization/policies
 888
 889     headers: Content-Type: application/json Accept: application/json
 890
 891     body:
 892       {
 893           "aaa:policies": {
 894               "aaa:policies": [
 895                   {
 896                       "aaa:resource": "/restconf/modules/**",
 897                       "aaa:index": 1,
 898                       "aaa:permissions": [
 899                           {
 900                               "aaa:role": "admin",
 901                               "aaa:actions": [
 902                                   "get",
 903                                   "post",
 904                                   "put",
 905                                   "patch",
 906                                   "delete"
 907                               ]
 908                           }
 909                       ]
 910                   }
 911               ]
 912           }
 913       }
 914
 915 The above example locks down access to the modules endpoint (and any URLS
 916 available past modules) to the "admin" role. Thus, an attempt from the OOB
 917 *admin* user will succeed with 2XX HTTP status code, while an attempt from the
 918 OOB *user* user will fail with HTTP status code 401, as the user *user* is not
 919 granted the "admin" role.
 920
 921 Accounting Configuration
 922 ------------------------
 923
 924 Accounting is handled through the standard slf4j logging mechanisms used by the
 925 rest of OpenDaylight. Thus, one can control logging verbosity through
 926 manipulating the log levels for individual packages and classes directly through
 927 the Karaf console, JMX, or etc/org.ops4j.pax.logging.cfg. In normal operations,
 928 the default levels exposed do not provide much information about AAA services;
 929 this is due to the fact that logging can severely degrade performance.
 930
 931 All AAA logging is output to the standard karaf.log file. For debugging purposes
 932 (i.e., to enable maximum verbosity), issue the following command:
 933
 934 ::
 935
 936     log:set TRACE org.opendaylight.aaa
 937
 938 Enable Successful/Unsuccessful Authentication Attempts Logging
 939 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 940
 941 By default, successful/unsuccessful authentication attempts are NOT logged. This
 942 is due to the fact that logging can severely decrease REST performance.
 943 To enable logging of successful/unsuccessful REST attempts, issue the following
 944 command in Karaf's console:
 945
 946 ::
 947
 948     log:set DEBUG org.opendaylight.aaa.shiro.filters.AuthenticationListener
 949
 950 It is possible to add custom AuthenticationListener(s) to the Shiro-based
 951 configuration, allowing different ways to listen for successful/unsuccessful
 952 authentication attempts. Custom AuthenticationListener(s) must implement
 953 the org.apache.shiro.authc.AuthenticationListener interface.
 954
 955 .. _certificate-management:
 956
 957 Certificate Management
 958 ----------------------
 959
 960 The **Certificate Management Service** is used to manage the keystores and
 961 certificates at the OpenDaylight distribution to easily provides the TLS
 962 communication.
 963
 964 The Certificate Management Service managing two keystores:
 965
 966 1. **OpenDaylight Keystore** which holds the OpenDaylight distribution
 967    certificate self sign certificate or signed certificate from a root CA based
 968    on generated certificate request.
 969
 970 2. **Trust Keystore** which holds all the network nodes certificates that shall
 971    to communicate with the OpenDaylight distribution through TLS communication.
 972
 973 The Certificate Management Service stores the keystores (OpenDaylight & Trust)
 974 as *.jks* files under configuration/ssl/ directory. Also the keystores
 975 could be stored at the MD-SAL datastore in case OpenDaylight distribution
 976 running at cluster environment. When the keystores are stored at MD-SAL,
 977 the Certificate Management Service rely on the **Encryption-Service** to encrypt
 978 the keystore data before storing it to MD-SAL and decrypted at runtime.
 979
 980 How to use the Certificate Management Service to manage the TLS communication
 981 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 982
 983 The following are the steps to configure the TLS communication:
 984
 985 1. After starting the distribution, the *odl-aaa-cert* feature has to get
 986 installed. Use the following command at Karaf CLI to check.
 987
 988 .. code-block:: bash
 989
 990   opendaylight-user@root>feature:list -i | grep aaa-cert
 991   odl-aaa-cert | 0.5.0-SNAPSHOT | x | odl-aaa-0.5.0-SNAPSHOT | OpenDaylight :: AAA :: aaa certificate Service
 992
 993 2. The initial configuration of the Certificate Manager Service exists under
 994 the distribution directory etc/opendaylight/datastore/initial/config/aaa-cert-config.xml.
 995
 996 .. code-block:: xml
 997
 998   <aaa-cert-service-config xmlns="urn:opendaylight:yang:aaa:cert">
 999     <use-config>false</use-config>
1000     <use-mdsal>false</use-mdsal>
1001     <bundle-name>opendaylight</bundle-name>
1002     <ctlKeystore>
1003       <name>ctl.jks</name>
1004       <alias>controller</alias>
1005       <store-password/>
1006       <dname>CN=ODL, OU=Dev, O=LinuxFoundation, L=QC Montreal, C=CA</dname>
1007       <validity>365</validity>
1008       <key-alg>RSA</key-alg>
1009       <sign-alg>SHA1WithRSAEncryption</sign-alg>
1010        <keysize>1024</keysize>
1011        <cipher-suites>
1012          <suite-name />
1013        </cipher-suites>
1014     </ctlKeystore>
1015     <trustKeystore>
1016       <name>truststore.jks</name>
1017       <store-password/>
1018     </trustKeystore>
1019   </aaa-cert-service-config>
1020
1021
1022 Now as it is explained above, the Certificate Manager Service support two mode
1023 of operations; cluster mode and single mode. To use the single mode change the
1024 use-config to true and it is recommended as long as there is no need for
1025 cluster environment. To use the cluster mode change the use-config and
1026 use-mdsal configurations to true and the keystores will be stored and shard
1027 across the cluster nodes within the MD-SAL datastore.
1028
1029 The initial password become randomly generated when the *aaa-cert* feature is
1030 installed.
1031
1032 The cipher suites can be restricted by changing the **<cipher-suites>**
1033 configuration, however, the JDK has to be upgraded by installing the `Java
1034 Cryptography Extension
1035 <http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html>`_
1036 policy.
1037
1038 .. code-block:: xml
1039
1040   <cipher-suites>
1041     <suite-name>TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384</suite-name>
1042   </cipher-suites>
1043     <cipher-suites>
1044   <suite-name>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384</suite-name>
1045     </cipher-suites>
1046   <cipher-suites>
1047     <suite-name>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384</suite-name>
1048   </cipher-suites>
1049
1050 3. The new configurations will take affect after restarting the distribution.
1051
1052 4. Now to add or get certificate to the OpenDaylight and Trust keystores, the
1053 Certificate Manager Service provides the following RPCs.
1054
1055 ::
1056
1057   a) Set the node certificate that will communicate with OpeDaylight through TLS
1058   connection.
1059   POST /operations/aaa-cert-rpc:setNodeCertifcate
1060   {
1061     "input": {
1062       "node-cert": "string",
1063       "node-alias": "string"
1064     }
1065   }
1066
1067 ::
1068
1069   b) Get the node certificate based on node alias.
1070   POST /operations/aaa-cert-rpc:getNodeCertifcate
1071   {
1072     "input": {
1073       "node-alias": "string"
1074     }
1075   }
1076
1077 ::
1078
1079   c) Get the OpeDaylight keystore certificate.
1080   POST /operations/aaa-cert-rpc:getODLCertificate
1081   {
1082     output {
1083       odl-cert "string"
1084     }
1085   }
1086
1087 ::
1088
1089   d) Generate a certificate request from the OpeDaylight keystore to be signed
1090   by a CA.
1091   POST /operations/aaa-cert-rpc:getODLCertificateReq
1092   {
1093     output {
1094       odl-cert-req "string"
1095     }
1096   }
1097
1098 ::
1099
1100   e) Set the OpeDaylight certificate, the certificate should be generated
1101   based on a certificate request generated from the ODL keystore otherwise the
1102   certificated will not be added.
1103   POST /operations/aaa-cert-rpc:setODLCertificate
1104   {
1105     "input": {
1106       "odl-cert-alias": "string",
1107       "odl-cert": "string"
1108     }
1109   }
1110
1111 .. note::
1112
1113   The Certificate Manager Service RPCs are allowed only to the Role Admin Users
1114   and it could be completely disabled through the shiro.ini config file. Check
1115   the URL section at the shiro.ini.
1116
1117 Encryption Service
1118 ------------------
1119
1120 The **AAA Encryption Service** is used to encrypt the OpenDaylight's users'
1121 passwords and TLS communication certificates. This section shows how to use the
1122 AAA Encryption Service with an OpenDaylight distribution project to encrypt data.
1123
1124 The following are the steps to configure the Encryption Service:
1125
1126 1. After starting the distribution, the *aaa-encryption-service* feature has to
1127    get installed. Use the following command at Karaf CLI to check.
1128
1129    .. code-block:: bash
1130
1131       opendaylight-user@root>feature:list -i | grep aaa-encryption-service
1132       odl-aaa-encryption-service | 0.5.0-SNAPSHOT | x | odl-aaa-0.5.0-SNAPSHOT | OpenDaylight :: AAA :: Encryption Service
1133
1134 2. The initial configuration of the Encryption Service exists under the
1135    distribution directory etc/opendaylight/datastore/initial/config/aaa-encrypt-service-config.xml
1136
1137    .. code-block:: xml
1138
1139       <aaa-encrypt-service-config xmlns="config:aaa:authn:encrypt:service:config">
1140         <encrypt-key/>
1141         <encrypt-salt/>
1142         <encrypt-method>PBKDF2WithHmacSHA1</encrypt-method>
1143         <encrypt-type>AES</encrypt-type>
1144         <encrypt-iteration-count>32768</encrypt-iteration-count>
1145         <encrypt-key-length>128</encrypt-key-length>
1146         <cipher-transforms>AES/CBC/PKCS5Padding</cipher-transforms>
1147       </aaa-encrypt-service-config>
1148
1149    .. note::
1150
1151       Both the initial encryption key and encryption salt become randomly generated
1152       when the *aaa-encryption-service* feature is installed.
1153
1154 3. Finally the new configurations will take affect after restarting the
1155    distribution.
1156
1157 Using the AAA Command Line Interface (CLI)
1158 ------------------------------------------
1159 The AAA offers a CLI through the Karaf's console. This CLI allows the user to
1160 configure and use some of the functionalities provided by AAA.
1161
1162 The AAA CLI exists under the **odl-aaa-cli** feature. This feature can be
1163 installed by executing the following command.
1164
1165 ::
1166
1167   feature:install odl-aaa-cli
1168
1169 To check that the installation of the feature succeeded type "aaa" and press
1170 *tab* to see the list of available commands under the *aaa* scope.
1171
1172 ::
1173
1174   opendaylight-user@root>aaa:
1175   aaa:add-domain           aaa:add-grant            aaa:add-role             aaa:add-user
1176   aaa:change-user-pwd      aaa:export-keystores     aaa:gen-cert-req         aaa:get-cipher-suites
1177   aaa:get-domains          aaa:get-node-cert        aaa:get-odl-cert         aaa:get-roles
1178   aaa:get-tls-protocols    aaa:get-users            aaa:import-keystores     aaa:remove-domain
1179   aaa:remove-grant         aaa:remove-role          aaa:remove-user
1180
1181 Add a User
1182 ^^^^^^^^^^
1183
1184 The *add-user* command allows for adding an OpenDaylight user. The following
1185 user parameters can be specified.
1186
1187 ::
1188
1189   aaa:add-user --userName <user name>
1190                --roleName <role>
1191                --userDescription <user description>
1192                --userEmail <user email>
1193                --domainName <domain name>
1194
1195 List available Users
1196 ^^^^^^^^^^^^^^^^^^^^
1197
1198 The *get-users* command list all the available users within the Controller.
1199
1200 ::
1201
1202   aaa:get-users
1203
1204     user
1205     admin
1206
1207 Remove a User
1208 ^^^^^^^^^^^^^
1209
1210 The *remove-user* command allows for removing an OpenDaylight user. The command
1211 needs the user name as parameter.
1212
1213 ::
1214
1215   aaa:remove-user --name <user name>
1216
1217 Change the OpenDaylight user password
1218 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1219
1220 The *change-user-pwd* command allows for changing the OpenDaylight user's
1221 password. It takes the user name as argument then will ask for the given user
1222 current password.
1223
1224 ::
1225
1226   aaa:change-user-pwd --userName admin
1227     Enter current password:
1228     Enter new password:
1229     admin's password has been changed
1230
1231 Add a Role
1232 ^^^^^^^^^^
1233
1234 The *add-role* command allows for adding a role to the Controller.
1235
1236 ::
1237
1238   aaa:add-role --roleName <role name>
1239                --roleDescription <role description>
1240                --domainName <domain name>
1241
1242 List available Roles
1243 ^^^^^^^^^^^^^^^^^^^^
1244
1245 The *get-roles* command list all the available roles within the controller.
1246
1247 ::
1248
1249   aaa:get-roles
1250
1251     user
1252     admin
1253
1254 Remove a Role
1255 ^^^^^^^^^^^^^
1256
1257 The *remove-role* command allows for removing an OpenDaylight role. The command
1258 needs the role name as parameter.  The role will be removed from those users who
1259 have it.
1260
1261 ::
1262
1263   aaa:remove-role --roleName <role name>
1264
1265 Add a Domain
1266 ^^^^^^^^^^^^
1267
1268 The *add-domain* command allows for adding a domain to the Controller.
1269
1270 ::
1271
1272   aaa:add-domain --domainName <domain name>
1273                  --domainDescription <domain description>
1274
1275 List available Domains
1276 ^^^^^^^^^^^^^^^^^^^^^^
1277
1278 The *get-domains* command list all the available domains within the controller.
1279 The system asks for the administrator credentials to execute this command.
1280
1281 ::
1282
1283   aaa:get-domains
1284
1285     sdn
1286
1287 Remove a Domain
1288 ^^^^^^^^^^^^^^^
1289
1290 The *remove-domain* command allows for removing an OpenDaylight role. The command
1291 needs the domain name as parameter.
1292
1293 ::
1294
1295   aaa:remove-domain --domainName <domain name>
1296
1297 Add a Grant
1298 ^^^^^^^^^^^
1299
1300 The *add-grant* command allows for creating a grant for an existing user. The
1301 command returns a grant id for that user.
1302
1303 ::
1304
1305   aaa:add-grant --userName <user name>
1306                 --domainName <domain name>
1307                 --roleName <role name>
1308
1309 Remove a Grant
1310 ^^^^^^^^^^^^^^
1311
1312 The *remove-grant* command allows for removing an OpenDaylight grant. This command
1313 needs the user name, domain and and role as parameters.
1314
1315 ::
1316
1317   aaa:remove-grant --userName <user name>
1318                    --domainName <domain name>
1319                    --roleName <role name>
1320
1321 Generate Certificate Request
1322 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1323
1324 Generate certificate request command will generate a certificate request based
1325 on the generated OpenDaylight keystore and print it on the Karaf CLI. The system
1326 asks for the keystore password.
1327
1328 ::
1329
1330   aaa:gen-cert-req
1331
1332   -----BEGIN CERTIFICATE REQUEST-----
1333   MIIBlzCCAQACAQAwWTELMAkGA1UEBhMCQ0ExFDASBgNVBAcMC1FDIE1vbnRyZWFsMRgwFgYDVQQKDA
1334   9MaW51eEZvdW5kYXRpb24xDDAKBgNVBAsMA0RldjEMMAoGA1UEAwwDT0RMMIGfMA0GCSqGSIb3DQEB
1335   AQUAA4GNADCBiQKBgQCCmLW6j+JLYJM5yAMwscw/CHqPnp5elPa1YtQsHKEAvp1I+mLVtHKZeXeteA
1336   kyp6ORxw6KQ515fcDyQVrRJiSM15jUd27UaFq5ku0+qJeG+Qh2btx+cvNSE7/+cgUWWosKz4Aff5F5
1337   FqR62jLUTNzqCvoaTbZaOnLYVq+O2dYyZwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBADhDr4Jm7gVm/o
1338   p861/FShyw1ZZscxOEl2TprJZiTO6sn3sLptQZv8v52Z+Jm5dAgr7L46c97Xfa+0j6Y4LXNb0f88lL
1339   RG8PxGbk6Tqbjqc0WS+U1Ibc/rcPK4HEN/bcYCn+Na1gLBaFXUPg08ozG6MwqFNeS5Z0jz1W0D9/oiao
1340   -----END CERTIFICATE REQUEST-----
1341
1342 Get OpenDaylight Certificate
1343 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1344
1345 The *get-odl-certificate* command will print the OpenDaylight certificate at the
1346 Karaf CLI. The system asks for the keystore password.
1347
1348 ::
1349
1350   aaa:get-odl-cert -storepass <store_password>
1351
1352   -----BEGIN CERTIFICATE-----
1353   MIICKTCCAZKgAwIBAgIEI75RWDANBgkqhkiG9w0BAQUFADBZMQwwCgYDVQQDDANPREwxDDAKBgNVBA
1354   sMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkG
1355   A1UEBhMCQ0EwHhcNMTYxMTMwMTYyNDE3WhcNMTcxMTMwMTYyNDE3WjBZMQwwCgYDVQQDDANPREwxDD
1356   AKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVh
1357   bDELMAkGA1UEBhMCQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIKYtbqP4ktgkznIAzCxzD
1358   8Ieo+enl6U9rVi1CwcoQC+nUj6YtW0cpl5d614CTKno5HHDopDnXl9wPJBWtEmJIzXmNR3btRoWrmS
1359   7T6ol4b5CHZu3H5y81ITv/5yBRZaiwrPgB9/kXkWpHraMtRM3OoK+hpNtlo6cthWr47Z1jJnAgMBAA
1360   EwDQYJKoZIhvcNAQEFBQADgYEAL9DK/P/yEBre3Mg3bICAUAvSvZic+ydDmigWLsY4J3UzKdV2f1jI
1361   s+rQTEgtlHShBf/ed546D49cp3XEzYrcxgILhGXDziCrUK0K1TiYqPTp6FLijjdydGlPpwuMyyV5Y0
1362   iDiRclWuPz2fHbs8WQOWNs6VQ+WaREXtEsEC4qgSo=
1363   -----END CERTIFICATE-----
1364
1365 Get Cipher Suites
1366 ^^^^^^^^^^^^^^^^^
1367
1368 The *get-cipher-suites* command shows the cipher suites supported by the
1369 JVM used by the OpenDaylight controller in TLS communication. For example, here
1370 are the `Default Ciphers Suites in JDK 8 <http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites>`_.
1371
1372 ::
1373
1374   aaa:get-cipher-suites
1375
1376     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
1377     TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
1378     TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
1379
1380 Get TLS Protocols
1381 ^^^^^^^^^^^^^^^^^
1382
1383 The *get-tls-protocols* command shows the TLS protocols supported by the
1384 JVM used by the OpenDaylight controller. For example, the JDK 8 supports the
1385 following TLS protocols: TLSv1.2 (default), TLSv1.1, TLSv1 and SSLv3.
1386
1387 ::
1388
1389   aaa:get-tls-protocols
1390
1391     TLS_KRB5_WITH_RC4_128_SHA
1392     TLS_KRB5_WITH_RC4_128_MD5
1393     TLS_KRB5_WITH_3DES_EDE_CBC_SHA
1394     TLS_KRB5_WITH_3DES_EDE_CBC_MD5
1395     TLS_KRB5_WITH_DES_CBC_SHA
1396
1397 Get Node Certificate
1398 ^^^^^^^^^^^^^^^^^^^^
1399
1400 The *get-node-cert* command prints a certificate for a given network node alias.
1401 This command is useful to check if the network node certificate has been added
1402 properly to the truest keystore. It takes the certificate alias as arguments.
1403
1404 ::
1405
1406   aaa:get-node-cert -alias ovs1
1407   -----BEGIN CERTIFICATE-----
1408   MIICKTCCAZKgAwIBAgIEI75RWDANBgkqhkiG9w0BAQUFADBZMQwwCgYDVQQDDANPREwxDDAKBgNVBA
1409   sMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVhbDELMAkG
1410   A1UEBhMCQ0EwHhcNMTYxMTMwMTYyNDE3WhcNMTcxMTMwMTYyNDE3WjBZMQwwCgYDVQQDDANPREwxDD
1411   AKBgNVBAsMA0RldjEYMBYGA1UECgwPTGludXhGb3VuZGF0aW9uMRQwEgYDVQQHDAtRQyBNb250cmVh
1412   bDELMAkGA1UEBhMCQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIKYtbqP4ktgkznIAzCxzD
1413   8Ieo+enl6U9rVi1CwcoQC+nUj6YtW0cpl5d614CTKno5HHDopDnXl9wPJBWtEmJIzXmNR3btRoWrmS
1414   7T6ol4b5CHZu3H5y81ITv/5yBRZaiwrPgB9/kXkWpHraMtRM3OoK+hpNtlo6cthWr47Z1jJnAgMBAA
1415   EwDQYJKoZIhvcNAQEFBQADgYEAL9DK/P/yEBre3Mg3bICAUAvSvZic+ydDmigWLsY4J3UzKdV2f1jI
1416   s+rQTEgtlHShBf/ed546D49cp3XEzYrcxgILhGXDziCrUK0K1TiYqPTp6FLijjdydGlPpwuMyyV5Y0
1417   iDiRclWuPz2fHbs8WQOWNs6VQ+WaREXtEsEC4qgSo=
1418   -----END CERTIFICATE-----
1419
1420 Export Keystores
1421 ^^^^^^^^^^^^^^^^
1422
1423 The *export-keystores* command exports the default MD-SAL Keystores to .jks
1424 files in the default directory for keystores (configuration/ssl/).
1425
1426 ::
1427
1428   aaa:export-keystores
1429
1430     Default directory for keystores is configuration/ssl/
1431
1432 Import Keystores
1433 ^^^^^^^^^^^^^^^^
1434
1435 The *import-keystores* command imports the default MD-SAL Keystores. The
1436 keystores (odl and trust) should exist under default SSL directory
1437 (configuration/ssl/).
1438
1439 .. code-block:: bash
1440
1441   aaa:import-keystores --trustKeystoreName <name of the trust keystore>
1442                        --trustKeystorePwd <password for the trust keystore>
1443                        --odlKeystoreName <name of the ODL keystore>
1444                        --odlKeystorePwd <password for the ODL keystore>
1445                        --odlKeystoreAlias <alias of the ODL keystore>
1446                        --tlsProtocols <list of TLS protocols separated by ','>
1447                        --cipherSuites <list of Cipher suites separated by ','>
1448
1449 .. warning::
1450
1451   It is strongly recommended to run the history clear command after you execute
1452   all the AAA CLI commands so Karaf logs stay clean from any adversary.
1453
1454   ::
1455
1456     history -c