-== Authentication Service\r
+== Authentication and Authorization Services\r
+\r
+=== Authentication Service\r
Authentication uses the credentials presented by a user to identify the user.\r
\r
-NOTE: The Authentication user store provided in the Lithium release does not fully support a clustered node deployment. Specifically, the AAA user store provided by the H2 database needs to be synchronised using out of band means. The AAA Token cache is however cluster-capable.\r
+NOTE: The Authentication user store provided in the Lithium release does not fully support a clustered node deployment. Specifically, the AAA user store provided by the H2 database needs to be synchronized using out of band means. The AAA Token cache is however cluster-capable.\r
\r
-=== Authenthentication data model\r
+==== Authentication data model\r
A user requests authentication within a domain in which the user has defined roles.\r
The user chooses either of the following ways to request authentication:\r
\r
* Provides credentials\r
* Creates a token scoped to a domain. In OpenDaylight, a domain is a grouping of resources (direct or indirect, physical, logical, or virtual) for the purpose of access control.\r
\r
-==== Terms and definitions in the model\r
+===== Terms and definitions in the model\r
Token:: A claim of access to a group of resources on the controller\r
Domain:: A group of resources, direct or indirect, physical, logical, or virtual, for the purpose of access control\r
User:: A person who either owns or has access to a resource or group of resources on the controller\r
Client:: A service or application that requires access to the controller\r
Claim:: A data set of validated assertions regarding a user, e.g. the role, domain, name, etc.\r
\r
-==== Authentication methods\r
+===== Authentication methods\r
There are three ways a user may authenticate in OpenDaylight: +\r
\r
* Basic HTTP Authentication\r
** Regular, non-token based, authentication with username/password.\r
* Token-based Authentication\r
-** Direct authentication: A user presents username/password and a domain the user wishes to access to the controller and obtains a timed (default is 1 hour) scoped access token. The user then uses this token to access Restconf (for example).\r
-** Federated authentication: A user presents credentials to a third-party Identity Provider (for example, SSSD) trusted by the controller. Upon successful authentication, the controller returns a refresh (unscoped) token with a list of domains that the user has access to. The user then presents this refresh token scoped to a domain that the user has access to obtain a scoped access token. The user then uses this access token to access Restconf (for example).\r
+** Direct authentication: A user presents username/password and a domain the user wishes to access to the controller and obtains a timed (default is 1 hour) scoped access token. The user then uses this token to access RESTCONF (for example).\r
+** Federated authentication: A user presents credentials to a third-party Identity Provider (for example, SSSD) trusted by the controller. Upon successful authentication, the controller returns a refresh (unscoped) token with a list of domains that the user has access to. The user then presents this refresh token scoped to a domain that the user has access to obtain a scoped access token. The user then uses this access token to access RESTCONF (for example).\r
\r
\r
-===== Example with token authentication using curl:\r
+====== Example with token authentication using curl:\r
\r
(username/password = admin/admin, domain = sdn)\r
\r
curl -ik -H 'Authorization:Bearer ed3e5e05-b5e7-3865-9f63-eb8ed5c87fb9' http://localhost:8181/restconf/config/toaster:toaster\r
----\r
\r
-===== Example with basic HTTP auth using curl: +\r
+====== Example with basic HTTP auth using curl: +\r
\r
[source,bash] \r
---- \r
curl -ik -u 'admin:admin' http://localhost:8181/restconf/config/toaster:toaster\r
----\r
\r
-=== How the OpenDaylight Authentication Service works\r
+==== How the OpenDaylight Authentication Service works\r
In direct authentication, a service relationship exists between the user and the OpenDaylight controller. The user and the controller establish trust that allows them to use, and validate credentials.\r
The user establishes user identity through credentials.\r
\r
\r
In a federated authentication set-up, the OpenDaylight controller AAA module provides SSSD claim support. SSSD can be used to map users in an external LDAP server to users defined on the OpenDaylight controller.\r
\r
-=== Configuring Authentication service\r
+==== Configuring Authentication service\r
Changes to AAA configurations can be made as follows:\r
\r
For Authentication functionality via one of:\r
For Token Cache Store settings via one of:\r
\r
* Editing the 08-authn-config.xml configuration file in etc/opendaylight/karaf\r
-* Using Restconf\r
+* Using RESTCONF\r
\r
NOTE: Configurations for AAA are all dynamic and require no restart.\r
\r
-==== Configuring Authentication\r
+===== Configuring Authentication\r
\r
To configure features from the Web console: +\r
\r
.. *Authorized Clients*: List of software clients that are authorized to access OpenDaylight northbound APIs.\r
.. *Enable Authentication*: Enable or disable authentication. (The default is enable.)\r
\r
-==== Configuring the token store\r
+===== Configuring the token store\r
. Open in a text editor etc/opendaylight/karaf/08-authn-config.xml\r
:: The fields you can configure are as follows:\r
.. *timeToLive*: Configure the maximum time, in milliseconds, that tokens are to be cached. Default is 360000.\r
\r
NOTE: When token's are expired, they are lazily removed from the cache.\r
\r
-==== Configuring AAA federation\r
+===== Configuring AAA federation\r
\r
. On the console, click *OpenDaylight AAA Federation Configuration*.\r
. Use the *Custom HTTP Headers* or *Custom HTTP Attributes* fields to specify the HTTP headers or attributes for federated authentication. Normally, additional specification beyond the default is not \r
\r
NOTE: As the changes you make to the configurations are automatically committed when they are saved, no restart of the Authentication service is required.\r
\r
-=== Configuring federated authentication\r
+====== Configuring federated authentication\r
Use the following steps to set up federated authentication: +\r
\r
. Set up an Apache front-end and Apache mods for the OpenDaylight controller.\r
. Set up mapping rules (from LDAP users to OpenDaylight users).\r
. Use the ClaimAuthFilter in federation to allow claim transformation.\r
\r
-=== Mapping users to roles and domains\r
+====== Mapping users to roles and domains\r
The OpenDaylight authentication service transforms assertions from an external federated IdP into Authentication Service data: +\r
\r
. The Apache web server which fronts OpenDaylight AAA sends data to SssdAuthFilter.\r
. SssdAuthFilter constructs a JSON document from the data.\r
. OpenDaylight Authentication Service uses a general purpose transformation mapper to transform the JSON document.\r
\r
-==== Operational model\r
+====== Operational model\r
The mapping model works as follows: +\r
\r
. Assertions from an IdP are stored in an associative array.\r
** The mapped values are taken from the local variables set during the rule execution.\r
** The definition of the rules and mapped results are expressed in JSON notation.\r
\r
-==== Operational Model: Sample code\r
+====== Operational Model: Sample code\r
[source,java]\r
----\r
mapped = null\r
return mapped\r
----\r
\r
-==== Mapping Users\r
+====== Mapping Users\r
A JSON Object acts as a mapping template to produce the final associative array of name/value pairs. The value in a name/value pair can be a constant or a variable.\r
An example of a mapping template and rule variables in JSON: +\r
Template: +\r
}\r
----\r
\r
-==== Example: Splitting a fully qualified username into user and realm components\r
+====== Example: Splitting a fully qualified username into user and realm components\r
Some IdPs return a fully qualified username (for example, principal or subject). The fully qualified username is the concatenation of the user name, separator, and realm name.\r
The following example shows the mapped result that returns the user and realm as independent values for the fully qualified username is bob@example.com .\r
\r
\r
The Authentication Service allows white lists for users with specific roles. The white lists ensure that users are unconditionally accepted and authorized with specific roles. Users who must be unconditionally denied access can be placed in a black list.\r
\r
-== Administering OpenDaylight Authentication Services\r
+=== Administering OpenDaylight Authentication Services\r
\r
-=== Actors in the System\r
+==== Actors in the System\r
*OpenDaylight Controller administrator* +\r
The OpenDaylight Controller administrator has the following responsibilities:\r
\r
* Gets access tokens either from a resource owner or the controller administrator\r
* Uses tokens at access applications from the north-bound APIs\r
\r
-=== System Components\r
+==== System Components\r
IdmLight Identity manager:: Stores local user authentication and authorization data, provides an Admin REST API for CRUD operations.\r
Pluggable authenticators:: Provides domain-specific authentication mechanisms\r
Authenticator:: Authenticates users against and establishes claims\r
Authentication Manager:: Contains the session token and authentication claim store\r
\r
\r
-==== IdmLight Identity manager\r
+===== IdmLight Identity manager\r
The Light-weight Identity Manager (IdmLight) Stores local user authentication and authorization data, and roles and provides an Admin REST API for CRUD operations on the users/roles/domains database.\r
The IdmLight REST API is by default accessed via the {controller baseURI:8181}/auth/v1/ API end point. \r
Access to the API is restricted to authenticated clients only, or those possessing a token:\r
https://wiki.opendaylight.org/images/a/ad/AAA_Idmlight_REST_APIs.xlsx\r
\r
\r
-== OpenDaylight Authorization Service\r
+=== OpenDaylight Authorization Service\r
The authorization service currently included in OpenDaylight is of an experimental kind and only briefly documented here. \r
-Authorization follows successful authentication and is modelled on the Role Based Access Control (RBAC) approach for defining permissions and decide access levels to API resources on the controller.\r
+Authorization follows successful authentication and is modeled on the Role Based Access Control (RBAC) approach for defining permissions and decide access levels to API resources on the controller.\r
\r
- *target-rib* - RIB ID of existing RIB where the data should be transferred
- *application-rib-id* - RIB ID of local application RIB (all the routes that you put to OpenDaylight will be displayed here)
-To populate RIB use //TODO: internal link to Populate RIB
+//TODO: internal link to Populate RIB
+//To populate RIB use
-In order to get routes advertised to other peers, you have to also configure the peers, as described in section BGP Peer //TODO: internal jump to section?
+//TODO: internal jump to section?
+//In order to get routes advertised to other peers, you have to also configure the peers, as described in section BGP Peer
=== Configuration through RESTCONF ===
include::core-release-notes.adoc[OpenDaylight Release Notes]
/////
-= Getting Started with Opendaylight
+= Getting Started with OpenDaylight
[partintro]
include::ch-clustering.adoc[Setting Up Clustering on an OpenDaylight Controller]
-= Addons
+= Applications and Plugins
[partintro]
include::aaa/aaa.adoc[AAA]
-include::vtn/vtn-user.adoc[]
-
include::bgpcep/odl-bgpcep-bgp-all-user.adoc[BGP]
-include::lacp/lacp-user.adoc[LACP]
+include::capwap/capwap-user.adoc[CAPWAP]
-include::bgpcep/odl-bgpcep-pcep-all-user.adoc[PCEP]
+include::didm/didm-user.adoc[]
include::l2switch/l2switch-user.adoc[]
-include::opflex/agent-ovs-user.adoc[]
+include::vpnservice/vpnservice-user.adoc[VPN Service]
+
+include::lacp/lacp-user.adoc[LACP]
include::lfm/lispflowmapping-all-user.adoc[LISP flow mapping]
-include::sdninterfaceapp/odl-sdninterfaceapp-all-user.adoc[ODL-SDNi]
+include::nic/nic-user.adoc[NIC]
-include::sfc/sfc.adoc[Service Function Chain]
+include::sdninterfaceapp/odl-sdninterfaceapp-all-user.adoc[ODL-SDNi]
-include::snmp/snmp-user-guide.adoc[SNMP]
+include::opflex/agent-ovs-user.adoc[]
-include::tcpmd5/odl-tcpmd5-all-user.adoc[TCP-MD5]
+include::bgpcep/odl-bgpcep-pcep-all-user.adoc[PCEP]
-include::usc/odl-usc-channel-user.adoc[USC]
+include::packetcable/packetcable-user.adoc[PacketCable PCMM - CMTS Management]
-include::ttp/ttp-cli-tools-user.adoc[TTP]
+include::sfc/sfc.adoc[Service Function Chain]
-include::capwap/capwap-user.adoc[CAPWAP]
+include::snmp/snmp-user-guide.adoc[SNMP]
-include::packetcable/packetcable-user.adoc[PacketCable PCMM - CMTS Management]
+include::sxp/odl-sxp-user.adoc[]
-include::tsdr/tsdr-hbase-user.adoc[]
+include::tcpmd5/odl-tcpmd5-all-user.adoc[TCP-MD5]
include::tsdr/tsdr-h2-user.adoc[]
-include::didm/didm-user.adoc[]
+include::tsdr/tsdr-hbase-user.adoc[]
-include::nic/nic-user.adoc[NIC]
+include::ttp/ttp-cli-tools-user.adoc[TTP]
-include::vpnservice/vpnservice-user.adoc[VPN Service]
+include::usc/odl-usc-channel-user.adoc[USC]
-include::sxp/odl-sxp-user.adoc[]
+include::vtn/vtn-user.adoc[]
configuration, administration, and management sections for the feature.
=== Overview
-CAPWAP feature fills the gap Opendaylight Controller has with respect to managing
+CAPWAP feature fills the gap OpenDaylight Controller has with respect to managing
CAPWAP compliant wireless termination point (WTP) network devices present
in enterprise networks. Intelligent applications (e.g. centralized firmware
management, radio planning) can be developed by tapping into the
'''
-. Download and unzip a base controller distribution. You must use the new openflow plugin, so download a distribution where the new openflow plugin is either the default or can be enabled.
+. Download and unzip a base controller distribution. You must use the new OpenFlow plugin, so download a distribution where the new OpenFlow plugin is either the default or can be enabled.
. Navigate to the _<Karaf-distribution-location>_/bin directory.
. Run Karaf: *./karaf*
. Install the clustering feature: *feature:install odl-mdsal-clustering*
The Topology tab displays a graphical representation of network topology created.
-NOTE: DLUX UI does not provide ability to add topology information. The Topology should be created using an open flow plugin. Controller stores this information in the database and displays on the DLUX page, when the you connect to the controller using openflow.
+NOTE: DLUX UI does not provide ability to add topology information. The Topology should be created using an OpenFlow plugin. Controller stores this information in the database and displays on the DLUX page, when the you connect to the controller using OpenFlow.
To view network topology:
.Topology Module
image::dlux-topology.png["DLUX Topology Page",width=500]
-=== Interacting with the Open Daylight Controller (ODL)
+=== Interacting with OpenDaylight
The *Yang UI* module enables you to interact with the ODL. For more information about Yang Tools, see https://wiki.opendaylight.org/view/YANG_Tools:Main [YANG_Tools].
When entering a command in the XSQL console, structure it as follows: *odl:xsql* _<XSQL command>_
-The following table describes the commands supported in the OpenDaylight Helium release.
+The following table describes the commands supported in this OpenDaylight release.
.Supported XSQL Console Commands
[cols="2",options="headers"]
support the APIs defined by the RPCs. There may be different Driver
implementations for different device types.
-=== Configuring DIDM
-TODO
-
-=== Administering or Managing DIDM
-TODO
+//=== Configuring DIDM
+//TODO
+//
+//=== Administering or Managing DIDM
+//TODO
=== Configuring L2Switch
This sections below give details about the configuration settings for the components that can be configured.
-The base distribution configuration files are located in distribution/base/target/distributions-l2switch-base-0.1.0-SNAPSHOT-osgipackage/opendaylight/configuration/initial
+//The base distribution configuration files are located in distribution/base/target/distributions-l2switch-base-0.1.0-SNAPSHOT-osgipackage/opendaylight/configuration/initial
-The karaf distribution configuration files are located in distribution/karaf/target/assembly/etc/opendaylight/karaf
+//The karaf distribution configuration files are located in distribution/karaf/target/assembly/etc/opendaylight/karaf
=== Configuring Loop Remover
* 52-loopremover.xml
=== Running the L2Switch project
-==== Check out the project using git
- git clone https://git.opendaylight.org/gerrit/p/l2switch.git
-
-The above command will create a directory called "l2switch" with the project.
-
-==== Run the distribution
-To run the base distribution, you can use the following command
-
- ./distribution/base/target/distributions-l2switch-base-0.1.0-SNAPSHOT-osgipackage/opendaylight/run.sh
-
-If you need additional resources, you can use these command line arguments:
-
- -Xms1024m -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=1024m'
-
-To run the karaf distribution, you can use the following command:
-
- ./distribution/karaf/target/assembly/bin/karaf
+To run the L2 Switch inside the Lithium OpenDaylight distribution simply install the `odl-l2switch-switch-ui` feature;
+
+ feature:install odl-l2switch-switch-ui
+
+//==== Check out the project using git
+// git clone https://git.opendaylight.org/gerrit/p/l2switch.git
+//
+//The above command will create a directory called "l2switch" with the project.
+//
+//==== Run the distribution
+//To run the base distribution, you can use the following command
+//
+// ./distribution/base/target/distributions-l2switch-base-0.1.0-SNAPSHOT-osgipackage/opendaylight/run.sh
+//
+//If you need additional resources, you can use these command line arguments:
+//
+// -Xms1024m -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=1024m'
+//
+//To run the karaf distribution, you can use the following command:
+//
+// ./distribution/karaf/target/assembly/bin/karaf
=== Create a network using mininet
sudo mn --controller=remote,ip=<Controller IP> --topo=linear,3 --switch ovsk,protocols=OpenFlow13
https://tools.ietf.org/html/draft-ietf-lisp-lcaf[LISP Canoncal Address Format
(LCAF)].
-The LISP Flow Mapping project in OopenDaylight implements support for many of
+The LISP Flow Mapping project in OpenDaylight implements support for many of
these different address formats, the full list being summarized in the
following table. While some of the address formats have well defined and
widely used textual representation, many don't. It became necessary to define
|Parameter| Description
|Name| NetNode descriptive name.
|ID| NetNode ID.
-|Type (read-only)| Default: Openflow
+|Type (read-only)| Default: OpenFlow
|SDN Node Mode (read-only)| Default: sdnenablednative.
|Health Check Interval (read- only)| Default: 60 seconds
|===
== OpenFlow Plugin
-Chapter on Open Flow Plugin
+Chapter on OpenFlow Plugin
* Abstract, event-based network resource auditing and management mechanisms,
* A robust security infrastructure that provides integrity and appropriate levels of protection across all interfaces.
-The goal of this project is to utilizes the OpenDayLight controller platform as for the Application Manager and parts of the Policy Server and leverage the as many existing components offered by the platform.
+The goal of this project is to utilizes the OpenDaylight controller platform as for the Application Manager and parts of the Policy Server and leverage the as many existing components offered by the platform.
The initial southbound transport has been written to the following version of the specification: http://www.cablelabs.com/wp-content/uploads/specdocs/PKT-SP-MM-I05-091029.pdf
[[pcmm-user-guide-preliminary]]
-== PCMM User Guide (*Preliminary*)
+== PCMM User Guide
[[system-overview]]
=== System Overview
[[Add CMTS]]
=== Adding a CMTS to OpenDaylight Inventory
-The RESTConf URLs makes it possible to add a CMTS to OpenDaylight and have it connected.
+The RESTCONF URLs makes it possible to add a CMTS to OpenDaylight and have it connected.
Add a CMTS to OpenDaylight Inventory
-image:Screenshot1.png[width=500,title="Add a CMTS to OpenDaylight Inventory"]
+image:Screenshot1.png[width=500]
[[postman]]
==== Postman
https://git.opendaylight.org/gerrit/gitweb?p=packetcable.git;a=tree;f=packetcable-client[Download
and import sample packetcable collection]
-
-image:Screenshot5.png[width=500,title="Postman Operations"]
-
+.Postman Operations
+image:Screenshot5.png[width=500]
* SDNi REST API: It is a part of controller northbound, which gives the required information by quering SDNiAggregator
* SDNiWrapper: This component uses the SDNi REST API and gathers the information required to be shared among controllers.
-=== Trouble shooting
+=== Troubleshooting
To work with multiple controllers, change some of the configuration in config.ini file. For example change the listening port of one controller to 6653 and other controller to 6663 in /root/controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-osgipackage/opendaylight/configuration/config.ini (i.e of.listenPort=6653).
-.Open Flow related system parameters
+.OpenFlow related system parameters
TCP port on which the controller is listening (default 6633) of.listenPort=6653
==== The way of getting SF monitor information
TBD
-===== SF netconf server configuration
+===== SF NETCONF server configuration
TBD
===== ODL configuration
include::odl-sfc-sf-scheduler-user.adoc[Service Function selection scheduler]
-include::odl-sfc-sf-monitoring-user.adoc[Service Function Monitoring]
+// Removed because there is no content
+// include::odl-sfc-sf-monitoring-user.adoc[Service Function Monitoring]
include::odl-sfc-load-balance-user.adoc[Service Function Grouping and Load Balancing user guide]
-== SNMP Plugin Installation Guide
+== SNMP Plugin User Guide
=== Installing Feature
The SNMP Plugin can be installed using a single karaf feature: *odl-snmp-plugin*
// . Step 2:
// . Step 3:
-=== Using the CLI Tools
-
-TODO: provide a few examples of using the CLI tools.
+// === Using the CLI Tools
+//
+// TODO: provide a few examples of using the CLI tools.
// <optional>
// If there is only one tutorial, you skip the "Tutorials" section and
== L3VPN Service: User Guide
=== Overview
-L3VPN Service in Opendaylight provides a framework to create L3VPN based on BGP-MP. It also helps to create Network Virtualization for DC Cloud environment.
+L3VPN Service in OpenDaylight provides a framework to create L3VPN based on BGP-MP. It also helps to create Network Virtualization for DC Cloud environment.
=== Modules & Interfaces
L3VPN service can be realized using the following modules -
==== Step 3 : OS Create Neutron Ports and attach VMs
-At this step user creates VMs. <TBD>
+At this step user creates VMs.
==== Step 4 : Create VM Interfaces
Create l2vlan interfaces corresponding to VM created in step 3
* <<_vtn_coordinator,VTN Coordinator>>
==== VTN Manager
-An OpenDaylight Controller Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in ODL controller. VTN Manager is implemented as one plugin to the OpenDaylight controller. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the ODC Driver component. In addition to the above mentioned role, it also provides an implementation to the Openstack L2 Network Functions API.
+An OpenDaylight Controller Plugin that interacts with other modules to implement the components of the VTN model. It also provides a REST interface to configure VTN components in ODL controller. VTN Manager is implemented as one plugin to the OpenDaylight controller. This provides a REST interface to create/update/delete VTN components. The user command in VTN Coordinator is translated as REST API to VTN Manager by the ODC Driver component. In addition to the above mentioned role, it also provides an implementation to the OpenStack L2 Network Functions API.
===== Features Overview
Code Review / docs.git / commitdiff