Hi,
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.
1781
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.
1860
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 }
and
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:
/ncs-config/aaa/validation-order
/ncs-config/aaa/external-validation/*
/ncs-config/restconf/token-response/*
/ncs-config/webui/custom-headers
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.
