Showing results for 
Search instead for 
Did you mean: 
Cisco Employee

Does NSO supports SSO

Does NSO supports (SSO)single sign on?

Is there any implementation for SSO into NSO?

Cisco Employee

NSO natively has the capability to authenticate using local username/password and PAM. All other authentication methods require 'external authentication'.  If external authentication is configured a call-out is made to a script outside of NSO that will execute to solicit authentication with external systems such as LDAP, TACACS, RADIUS, etc. I don't know much about SSO, but if authentication can be programmatically requested (client/server or API) then a script for NSO external authentication may be written.



Cisco Employee



Please refer to NSO admin guide - External Authentication.


You could take a look at /ncs-config/aaa/external-authentication/


In the tailf-ncs-config.yang file:


1762       container external-authentication {
1763         presence "";
1764         leaf enabled {
1765           type boolean;
1766           default false;
1767           description "
1768               When set to 'true', external authentication is used.";
1769         }
1770         leaf executable {
1771           type string;
1772           description "
1773               If we enable external authentication, an executable on the
1774               local host can be launched to authenticate a user.  The
1775               executable will receive the username and the cleartext
1776               password on its standard input. The format is
1777               '[${USER};${PASS};]\\n'. For example if user is 'bob' and
1778               password is 'secret', the executable will receive the line
1779               '[bob;secret;]' followed by a newline on its standard
1780               input. The program must parse this line.
1782               The task of the external program, which for example could
1783               be a RADIUS client is to authenticate the user and also
1784               provide the user to groups mapping. So if 'bob' is member
1785               of the 'oper' and the 'lamers' group, the program should
1786               echo 'accept oper lamers' on its standard output.  If the
1787               user fails to authenticate, the program should echo
1788               'reject ${reason}' on its standard output.";


and for the external-validation:


1842       container external-validation {
1843         presence "";
1844         leaf enabled {
1845           type boolean;
1846           default false;
1847           description
1848             "When set to 'true', external token validation is used.";
1849         }
1850         leaf executable {
1851           type string;
1852           description
1853             "If we enable external token validation, an executable on the
1854              local host can be launched to validate a user.  The
1855              executable will receive a cleartext token on its standard
1856              input. The format is '[${TOKEN};]\\n'. For example if the token is
1857              '7ea345123', the executable will receive the string '[7ea345123;]'
1858              followed by a newline on its standard input. The program must parse
1859              this line.
1861              The task of the external program, which for example could
1862              be a FUSION client, is to validate the token and also provide
1863              the token to user and groups mappings. Refer to the External
1864              validation section of the AAA chapter in the User
1865              Guide for the details of how the program should report the
1866              result back to NSO.";
1867         }




Currently, we have a 'token-authentication' mechanism for RESTCONF, where after
authentication, you can configure NSO to look for tokens in a cookie or in the
'x-auth-token' header. You can also configure an external validation program,
which will take this token as the input and return a username and a list of
groups, similar to how the external authentication works.

The plan is to extend this, so that NSO can get the token from a configurable
header (instead of the fixed x-auth-token header or a cookie, as it is now).
So, there would be changes to NSO's webui, addition of some new ncs.conf
parameters to specify which header to look for etc.

And the idea is for the customer to configure their ncs.conf, and also to write
this external validation program, which gets a token as the input, and is
expected to provide a username and a list of groups (ie., essentially a mapping
between a token and the username-groups).

The details are not fully figured out yet. Meanwhile, you can go through these
options in ncs.conf, to get an idea of how this feature would probably be done:


Also, please look at the section "External token validation" under
"Authentication" in chapter "The AAA Infrastructure" of the NSO Administration guide.


Hope this helps or provides valuable insight.

Cisco Employee

Thanks for the info, it was very useful.

Is there any workaround exists today to extract the HTTP header key from Web UI request and validate?