cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
77
Views
1
Helpful
4
Replies
Cisco Employee

NSO - GUI Access Questions

 

Hi All,

 

 

I have some questions about the NSO access of the GUI and its restrictions:

 

 

1/ How can I create an access rule which goes/descends lower, up to the service level? For example: dtNetscalerVipCreate.

   

Here, in the example below, the user, logged on to NSO has access to all services as you can see in the path (/services).

 

The question is, how to restrict access to only 1 service (dtNetscalerVipCreate) or services group?

 

 

   

 

2/ Is it possible to create sub-directories within the “packages” directory of NSO?

 

 

Such as:

 

/packages

 

/packages/Netscaler

 

/packages/Netscaler/dtNetscalerVipCreate

 

/packages/Netscaler/dtNetscalerVipBind

 

/packages/F5

 

/packages/F5/xxxx

 

 

 

3/ Is it possible to create a service that contains multiple XML files within the same template?

 

 

Example : /products/nso/Run/packages/my-service/templates

 

nsoadm@HNSOLX01: # ll

 

-rw-r--r-- 1 nsoadm nso 1212 May 31 17:34 dtNetscalerVipCreate.xml

 

-rw-r--r-- 1 nsoadm nso 1212 May 31 17:34 dtNetscalerRealserverAdd.xml

 

 

4/ Is it possible to restrict user access to the NSO GUI and give that user only access to the REST API (https://nso:8888/api/config/services/…)?

 

               

 

Many thanks for your help. This is all needed to make the GUI better accessible for my customer SG.

 

Kind regards,

 

 

Gerald

 

 

Everyone's tags (5)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: NSO - GUI Access Questions

 

Hi Gerald,

 

 

Regarding question 2, I don’t know about creating subdirectories, but if you’re looking to provide the operator with some kind of hierarchy (rather than hierarchy for the code location), then you can do something like this:

 

 

In one package, create a container, e.g:

 

container netscaler {

 

 

[you can also have a servicepoint here]

 

 

 

}

 

 

On the other packages, augment the same container. E.g:

 

 

augment /netscaler:netscaler {

 

 

uses ncs:service-data;

 

ncs:servicepoint netscaler-dtnetscaler-servicepoint;

 

 

 

}

 

 

This way, when the operator wants to access/create any service that augments the netscaler container, from the operator point of view, they’ll be all under /netscaler, regardless of the fact that each resides under different subdirectory in the packages directory.

 

 

 

 

Regarding question 2, I think this is not possible for a template-based service.

 

If you’d like to have multiple templates on the same service, you can have a Java-based service which will apply any number of templates.

 

 

The code will be very simple. Something like:

 

 

Template template;

 

 

template = new Template(context, “myTemplate1”);

 

template.apply(service, null);

 

 

template = new Template(context, “myTemplate2”);

 

template.apply(service, null);

 

 

 

 

 

 

template = new Template(context, “myTemplateN”);

 

template.apply(service, null);

 

 

 

 

hope that helps!

 

Yftach

 

View solution in original post

4 REPLIES 4
Highlighted
Cisco Employee

Re: NSO - GUI Access Questions

 

Hi Gerald,

 

 

Regarding question 2, I don’t know about creating subdirectories, but if you’re looking to provide the operator with some kind of hierarchy (rather than hierarchy for the code location), then you can do something like this:

 

 

In one package, create a container, e.g:

 

container netscaler {

 

 

[you can also have a servicepoint here]

 

 

 

}

 

 

On the other packages, augment the same container. E.g:

 

 

augment /netscaler:netscaler {

 

 

uses ncs:service-data;

 

ncs:servicepoint netscaler-dtnetscaler-servicepoint;

 

 

 

}

 

 

This way, when the operator wants to access/create any service that augments the netscaler container, from the operator point of view, they’ll be all under /netscaler, regardless of the fact that each resides under different subdirectory in the packages directory.

 

 

 

 

Regarding question 2, I think this is not possible for a template-based service.

 

If you’d like to have multiple templates on the same service, you can have a Java-based service which will apply any number of templates.

 

 

The code will be very simple. Something like:

 

 

Template template;

 

 

template = new Template(context, “myTemplate1”);

 

template.apply(service, null);

 

 

template = new Template(context, “myTemplate2”);

 

template.apply(service, null);

 

 

 

 

 

 

template = new Template(context, “myTemplateN”);

 

template.apply(service, null);

 

 

 

 

hope that helps!

 

Yftach

 

View solution in original post

Highlighted
Cisco Employee

Re: NSO - GUI Access Questions

 

Hi Yftach,

 

 

Sorry for the late answer. And thanks bye the way.

 

 

I’m not sure if I have been clear enough. Maybe we should have a small call/webex on this subject.

 

The issue is that my customer would like to know how to restrict access to the NSO for their different customers.

 

 

So, for example:

 

 

Customer 1 – Should have only access to HIS devices and services to execute.

 

    - DeviceA, DeviceB

 

    - ServiceA, ServiceB

 

Customer 2 – Should have only access to HIS devices and services to execute.

 

    - DeviceC, DeviceD

 

    - ServiceC, ServiceD

 

 

We should restrict all customers from being able of executing services from each other. Or accessing devices from each other.

 

 

This not only by the GUI as the customers won’t have access to it, but from the NSO services.

 

 

Can this be done? If yes, how shall we do that? Do we need to check for the connected user within the service we create?

 

Where do we specify all those rules?

 

 

Thanks in advance for your help.

 

Kind regards,

 

 

Gerald

 

Highlighted
Cisco Employee

Re: NSO - GUI Access Questions

 

Check the Authorization chapter in the NSO Admin Guide.

 

 

Highlighted
Cisco Employee

Re: NSO - GUI Access Questions

 

Thanks Hakan,

 

 

I will test it.

 

Cheers,

Gerald