Jump to content

  • Articles

    Show all categories
    Steven Wright
    In this two-part blog series, I describe how to rapidly create services on your NetScaler's using Citrix Application Delivery Management (ADM) StyleBook automation to accelerate migrations. In the example, we create 300 load balancers across an estate of several NetScaler's within 15 minutes.
    My first post was aimed at DevOps. In this post, I target Sysadmin employees and focus on a pre-prepared script that I wrote. The script helps you to achieve our goal of rapidly creating load balancing virtual servers.
    You can download the script and its two supporting files here.
    Note: The script requires Python 3 and jinja2, that you can install with pip using the command
    pip install jinja2 Prepare the StyleBook template("template.txt")
    The first of the script's two supporting files is named template.txt.
    The template.txt file is already preprepared for the simple HTTP load balancers that we create in this post, and you don't need to modify it. However, I do want to explain how you can make those modifications, in case you want to target other StyleBooks or introduce extra parameters.
    On the second line of the template.txt, you can find the namespace, version, and the name of the targeted StyleBook.
    StyleBook NAMESPACE/VERSION/STYLEBOOK com.citrix.adc.stylebooks/1.1/lb If you want to change the template file's target, you can view the namespace, version, and the name of another StyleBook within Citrix ADM's web interface.
     
     

     

    On lines five to 12 of the template.txt, you can find placeholder names that correspond to the columns in a CSV file called lbvserver.csv, which is also included with the script.
    CSV columns
    targetadc name lbvirtualip lbvirtualport lbservicetype svcservicetype svcservers: list svcserverport As you can see from the placeholder named svcservers: list, if the columns in the CSV file contain a list of items, such as a list of back-end servers for a load balancing virtual servers, we note this by appending ": list" to the placeholder's name.
    You can find a template with each value that our script must submit to the StyleBook at line 14. Each item in the template matches one of the placeholder values you created earlier, and the template includes a loop where it encounters a list.

    Template
    { "configpack": { "targets": [{"id": "<<targetadc>>"}], "parameters": { "lb-appname": "<<name>>", "lb-virtual-ip": "<<lbvirtualip>>", "lb-virtual-port": "<<lbvirtualport>>", "lb-service-type": "<<lbservicetype>>", "svc-service-type": "<<svcservicetype>>", "svc-servers": [ <% for server in svcservers %> { "port": << svcserverport >>, "ip": "<< server >>", "add-server": true }<<,>> <% endfor %> ] } } } Again, you need to edit the template file only you're modifying the script to target an alternative StyleBook or you're introducing extra parameters.


    Preparing the script
    As we saw in Part 1, you need an ID and secret to allow the script to log in into your Citrix ADM environment. If you're using the Citrix ADM service, you can create the ID and secret by doing the following steps:
    Sign in to the Citrix Cloud portal. Select Identity and Access Management from the menu. Select the API Access tab. Name your Secure Client, and click Create Client.  

     

    After you have the ID and secret, replace the placeholder example values within the create2.py python script.
    # Set my login variables for ADM # You can create an ID and secret by selecting the Identity and Access Management tab in your Cloud portal Id = "1707d2ff-e200-46be-848a-93faf2076d6b" Secret = "DIH1CzF_GSZG2zNnEVShLA=="` Preparing the Excel CSV template
    Now that you've set the ID and secret values, you can run the script with the "-a" parameter to display a list of NetScaler's and their identifiers.
    Command
    python create2.py -a Output
    The following NetScaler instances IDs can be referenced within your CSV file. Name - IP address - ID for use in CSV. 1\. bob - 192.168.1.240 - a0de40bb-e186-44bb-871b-d60f112b0a3a Here, we can observe that I have an NetScaler with the host name "bob" on IP address "192.168.1.240" with the unique identifier "a0de40bb-e186-44bb-871b-d60f112b0a3a." You must note each identifier because we need them later.

     
    Prepare a list of load balancing virtual server ("lbvserver.csv")
    The second of the script's two supporting files is named lbvserver.csv.
    Each row in the lbvserver.csv file includes the properties for a single StyleBook, in this case, the properties for a single HTTP Load Balancing virtual servers.
    Each column in the lbvserver.csv file is the source for the placeholders within the template.txt file. The columns and placeholders are in the same order, with the first column being the first placeholder and so on.
    I have expanded the lbvserver.csv file to contain 300 rows (300 HTTP Load Balancing virtual servers) for this post. If my customer had a similar requirement, I would likely populate an initial CSV with all the expected values. Then, they would forward the CSV internally to ensure that the names, naming conventions, and IP addresses were all as desired.
    As you can observe by comparing the columns to the template.txt file, column A specifies the unique identifier of the NetScaler that we target, and columns B to H are the input parameters for the StyleBook. You can include lists in the parameters with ":" used as a separator.
    After modifying the lbvserver.csv file to reflect the virtual servers that you want to create, you must save in "CSV" rather than "CSV (UTF8)" format.
     
     

     


    Running the script (python create2.py)
    Having populated the script with an ID and secret that allow access to your Citrix ADM environment and updated the columns to reflect which NetScaler you want to build on and the properties, we are now ready to create our load balancing virtual servers.
    We can now run the script and create a Citrix ADM config pack along with the resultant NetScaler configuration.
     
    Command
    python create2.py Output (shortened)
    Creating ADM Config Pack based on CSV row: 1 {"configpack": {"job_id": "1926702141"}} Creating ADM Config Pack based on CSV row: 2 {"configpack": {"job_id": "2520889571"}} Creating ADM Config Pack based on CSV row: 3 {"configpack": {"job_id": "2581540139"}} Creating ADM Config Pack based on CSV row: 4 {"configpack": {"job_id": "1440135035"}} Creating ADM Config Pack based on CSV row: 5 {"configpack": {"job_id": "3264746514"}} The script takes around two to three seconds per row and completes the 300 rows in just under 15 minutes. After completion, the resultant Config Packs will be visible within ADM.
     
    Ongoing maintenance
    In addition to creating the virtual servers rapidly from a pre-agreed Excel CSV file, this script-based approach also allows management of the resultant virtual servers using ADM and future changes without a need to understand the underlying commands on their NetScaler's.
    You can view each of the resultant Config Packs by selecting Applications, Configuration, Config Packs from within the Citrix ADM web interface. By selecting Edit, you can then manage and update the Config Pack as your needs change.
     

     
     

     
     

     
     
     
     
    Next steps
    We have now created 300 load balancers across our estate using an adaptable template that allows you not only to create load balancers but any other StyleBook based configuration.
    If you want to understand how the script works, you can read through the first article in this series .
    Mayur Vadhar
    NetScaler Ansible modules can be used for automating NetScaler configurations. It also contains a generic module called citrix_adc_nitro_request which doesn’t target a particular endpoint instead can be used to perform NITRO API operations on various endpoints.
    Using Nitro Request Ansible module
    Let’s go through the example and understand the  execution of citrix_adc_nitro_request module
    - name: Get lb vserver delegate_to: localhost register: result citrix_adc_nitro_request: nsip: "{{ nsip }}" nitro_user: "{{ nitro_user }}" nitro_pass: "{{ nitro_pass }}" operation: get resource: lbvserver name: lbvs1 As we can see there is a group of attributes that are common among all ansible NetScaler modules for connecting to the target NetScaler. After these, we have the operation attribute which is the key to the execution of the module. It instructs the module which operation to perform. In our case we want the get operation to get information for a particular NITRO object. After that, we have the attributes that will determine which object will be fetched. In our case, we want the resource lbvserver with the name lbvs1. The result is stored in the result variable for further processing by subsequent modules. We could for example print out its contents with the debug module.
    Supported Operations
    Apart from the get operation the citrix_adc_nitro_resource module supports the following operations:
    add update Get get_by_args get_filtered get_all delete delete_by_args count mas_login save_config action The add operation is used to create a new NITRO object.
    The update operation is used to update an existing object
    The get* operations are used to retrieve information for an object. They are differentiated by how we define the choice criteria for object retrieval.
    The delete and delete_by_args operations are used to delete existing objects.
    The count operation is used to return the count of a NITRO object.
    The mas_login operation is used to retrieve the authentication token from an ADM to use in subsequent calls where the ADM will be used as a NITRO API proxy.
    The save_config operation is used to save the configuration on the target NetScaler.
    Finally, the action operation is used to perform an action against a NITRO endpoint. The action can vary. For example. one action would be to enable a basic server.

    It is worth noting that nitro_request will try to do as little as possible of processing apart from the operation it is instructed to do. In this way, you can think of it as a thin wrapper around the Ansible URI module. It mainly will provide a more convenient and intuitive interface to perform an HTTP operation. As a consequence of that it will always report a changed state as it will not do any processing to determine if an actual configuration change took place in the target Netscaler.

    Despite these limitations, it is useful in its own right and also can be combined with the citrix_adc_nitro_resource module to perform more complex tasks. For example, we could use the nitro_resource module to create a server and then the nitro_request module to enable or disable the server. An example playbook of that is shown below where we create a server and then proceed to disable it.
    Although it is a bit artificial as an example it showcases how the two generic modules could be combined to achieve the desired configuration.
    - hosts: citrix_adc gather_facts: False vars_files: - deps/workflows.yaml collections: - citrix.adc tasks: - name: Setup server delegate_to: localhost citrix_adc_nitro_resource: nsip: "{{ nsip }}" nitro_user: "{{ nitro_user }}" nitro_pass: "{{ nitro_pass }}" validate_certs: "{{ validate_certs }}" state: present workflow: "{{ workflow.server }}" resource: name: test-server ipaddress: 192.168.11.34 - name: Disable server delegate_to: localhost register: result citrix_adc_nitro_request: nsip: "{{ nsip }}" nitro_user: "{{ nitro_user }}" nitro_pass: "{{ nitro_pass }}" validate_certs: "{{ validate_certs }}" operation: action action: disable resource: server attributes: name: test-server delay: 30 graceful: !!str yes Useful Resources :
    NetScaler Ansible modules repository ( https://github.com/citrix/citrix-adc-ansible-modules ) Nitro resource examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_resource ) Nitro request examples ( https://github.com/citrix/citrix-adc-ansible-modules/tree/master/samples/nitro_request )
    Steven Wright
    NetScaler migration
    Have you bought a new NetScaler with more throughput or is it time to refresh? Are you migrating from old NetScalers to new ones? Sounds difficult? Then you've stumbled across the right article. Installing new NetScalers into production and migrating services may seem like a complicated process, but once you know how to do it, it's much easier than you might think. This blog post will walk you through the steps needed.

    In this article, we will assume that you have an existing source NetScaler that's running in production and a new target NetScaler that you want to prepare in a non-production environment and migrate to under a change control process.



    Prepare for the migration (existing NetScaler)
    ADM Service's migration feature requires NetScaler firmware version 13.1.17 or above. To prepare for the upcoming migration, upgrade your existing NetScalers to 13.1.17 firmware so that both the source and target NetScaler have the same firmware version and support for ADM Service's migration feature.

    NetScaler recommends upgrading to the same firmware on the source and target NetScalers to minimize the number of changes during the migration and, in the unlikely event of any issues, to identify the cause more easily.

    You can upgrade your existing NetScaler to 13.1 firmware using the instructions here.


    Prepare for the migration (target NetScaler)
    First, install your new target NetScaler into a non-production environment without a connection to the production network. Ensuring the non-production and production networks are isolated from each other will prevent unintended interactions such as IP address conflicts.

    Once you have installed the new NetScaler, connect it to ADM Service. To do this, you need to add an ADM Agent into the non-production environment. You can install a new ADM Agent using the instructions here and add you can connect the new NetScaler to ADM Service using these instructions.

    Next, install a license onto your new NetScaler. You can apply a pooled license to your new NetScaler using the instructions here.



    Replicate the configuration
    After ensuring that the new NetScaler is not connected to any production networks, follow these steps to replicate the configuration.

    1. Select Infrastructure, Instances, NetScaler, and NetScaler form factor
    In the screenshot, we have selected the "VPX" form factor and can see two NetScalers, "192.168.6.30" and "192.168.1.230".

    In this article, we will use "192.168.6.30" as the source NetScaler and will replicate its configuration onto the target NetScaler on "192.168.1.230".
     

     
     
     
     

    2. Tick the source NetScaler, click "Select Action", and then choose "Replicate Configuration"
     
     
     
     
     

     
     
     

    3. Move the target NetScaler instance from the "Available" to "Configured" window using the arrow button and click "Create"
     
     


    ADM Service will now replicate the configuration from your source to target NetScaler.

    Note: Any existing configuration on the target instance will be erased and replaced with the configuration of the source NetScaler. The source and target NetScalers should be on separate networks to prevent IP conflicts.



    Validate the network configuration on the target NetScaler
    Although the source and target NetScalers will now have the same configuration, the management NSIP and network interface layout may differ.

    If you installed your new NetScaler into the non-production environment using a network interface layout that you don't want to use in production, you should change they layout now.

    To change the network configuration, log into the target NetScaler and ensure:
     
     
    That all unused interfaces are disabled That you have created LACP channels as you require That a SNIP is bound to each VLAN That each VLAN is bound to an interface or channel using your intended network layout
    You can find instructions detailing how to disable unused interfaces, create LACP channels, and how to bind SNIPs and VLANs here.


    Replace the NSIP on the target NetScaler
    If you installed your new NetScaler into the non-production environment using an NSIP that differs from production and would prefer it was the same at the point of migration, you should change the NSIP now.
    You can change the NSIP using the following steps.

    Note: If you are migrating an HA pair, you must perform the commands below on both nodes at the same time and shutdown both nodes at the same time.
     
    Select the target NetScaler within the "Infrastructure, Instances, NetScaler" menu of ADM, choose "SNMP" from "Select Action", then disable SNMP.
    Note: We are disabling these services to ensure they are not configured to communicate with the pre-production ADM Agent, we will re-enable them after the migration is complete.
     


     

     
     
     
    Using the same process as "step 1" (above), disable Syslog and Analytics on the target NetScaler.  
    Select the source NetScaler and repeat steps one and two (above) to disable SNMP, Syslog, and Analytics.  
    Log into the target NetScaler's command line interface using SSH. You can find details of how to use SSH here.  
    Change the NSIP of the target NetScaler using the commands shown in red. shell cd /nsconfig cp ns.conf ns.old sed -i -e 's/192.168.1.230/192.168.6.30/g' ns.conf Note: 192.168.6.30 is the source NetScaler in our example and 192.168.1.230 is the target NetScaler. You must replace the IP addresses within the command with those of your source and target NetScaler.
     
    Change references to the NSIP of the other HA node if applicable sed -i -e 's/192.168.1.231/192.168.6.31/g' ns.conf Note: You will run the sed command twice on both HA nodes. Firstly, to replace the NSIP of the current node. Secondly, to replace all references to that changed NSIP on its HA partner.
     
    Shutdown the NetScaler shutdown now Note: If you shutdown the NetScaler using an alternative command then you should reply "no" when ask if you wish to save the running configuration.

    The output will look like the text below.

    Note: In this example, we have included an example HA node with an NSIP of 192.168.1.231 that needs to be replaced with 192.168.6.31 - the replacement needs to be executed on both HA nodes.

    ###############################################################################
    #                                                                             #
    #        WARNING: Access to this system is for authorized users only          #
    #         Disconnect IMMEDIATELY if you are not an authorized user!           #
    #                                                                             #
    ###############################################################################

    Password:
    Last login: Mon Dec  6 14:26:05 2021 from 192.168.6.20
    Done
    nsroot@-Primary> shell
    Copyright (c) 1992-2013 The FreeBSD Project.
    Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
           The Regents of the University of California. All rights reserved.

    root@ns# cd /nsconfig
    root@ns# cp ns.conf ns.old
    root@ns# sed -i -e 's/192.168.1.230/192.168.6.30/g' ns.conf
    root@ns# sed -i -e 's/192.168.1.231/192.168.6.31/g' ns.conf
    root@ns# shutdown now
    Shutdown NOW!
    shutdown: [pid 8140]
    root@ns#                                                                               
    *** FINAL System shutdown message from root@ns ***                          

    System going down IMMEDIATELY                                                 

                                                                                  
    System shutdown time has arrived
    Connection to 192.168.6.30 closed by remote host.



    Replace the NetScaler under change control
    With the existing source and target NetScalers now having identical configurations, you can replace them in compliance with your change control procedures.

    Many customers achieve that change using a two-stage replacement process.

    In the first stage, they work with their network teams to connect the new NetScalers to network switch ports that are administratively disabled or offline.

    In the second stage, during a change control window, the network team places the switch ports to the old NetScalers into a disabled or offline state, brings the interfaces connecting the new NetScalers online, and flushes the ARP cache on their router.

    The effect is that all hardware installation and readiness activities can be completed in-advance and the change control window to move from the old to new appliances is completed in minutes. This approach also provides an excellent rollback strategy as the network could disable the interfaces connecting the new NetScaler and reenable those for the old, which are still powered on and running without modification.


    Re-establish connectivity to ADM Service
    You have now replaced the source NetScaler with the target. ADM will show the source as online (as the target is using the source NetScaler's NSIP) and the target's old NSIP as offline.

    You should now complete the following steps to ensure the migrated NetScaler is correctly communicating with ADM Service.
     
    To ensure ADM is communicating with the new NetScaler that has taken over the NSIPs of the source, select the source NetScaler within "Infrastructure, Instances, NetScaler" menu of ADM and, choose "Rediscover" from "Select Action".  
    After the rediscovery completes, re-enable the SNMP, Analytics, or Syslog capabilities that you disabled at step one of "Replace the NSIP on the target NetScaler". To enable each, select the NSIP of the source NetScaler and the capability under "Select Action".  
    If you are using pooled licensing on the new NetScaler, you must also ensure it is using the production ADM Agent as its license server. To do this, log into the new NetScaler using SSH and enter the following commands:
    sh nslicenseserver
     
    If the new NetScaler is not using the production ADM Agent as its license server, you can correct the license server to production ADM using the following commands:
    add nslicenseserver <prod_agent_ip> -port 27000 -forceUpdateIP
     
    Remove the target NetScaler's old NSIP from ADM by ticking the old NSIP within the "Infrastructure, Instances, NetScaler" menu of ADM and pressing "Remove".


    Next steps

    You have now finished migrating from your old to new NetScalers and can begin using them in production.
    Hemang Raval
    Submitted on:  May 10, 2021
    Author: Dharanikanth Dugginni   APIs are a critical infrastructure component and help to drive the modern digital economy. If your organization is using APIs, you can’t afford for them to go down. If your APIs are attacked successfully, it can lead to data loss, frustrated customers, and hits on your revenue and reputation. Strong authentication (Who is the client or user?) and authorization (What can the client or user do?) practices are essential to ensuring your APIs are secure.
    In this blog post, I’ll cover oAuth2.0, which has become the de facto standard for authenticating APIs and users in modern hybrid multi-cloud architectures (single-page apps, progressive web apps, mobile clients, and microservices). We’ll also look at how you can leverage the NetScaler API authentication and authorization solution to protect your APIs and simplify your app deployment.
    What Is oAuth2.0?
    oAuth2.0 provides an interoperable framework to convey authorization information. It uses short-lived tokens — JSON Web Tokens (JWT) or opaque tokens — with limited rights as a means to provide delegated access control.
    A valid token indicates that the client (user) has been authenticated and any requested permissions (claims) are present in the token, the permissions may be used for authorization policy decisions. Clients include the token in the requests using the Authorization header with “Bearer” type, like this:
    "Authorization: Bearer &lt;token&gt;" Other commonly used authentication methods like basic authentication and API keys are less secure because of the risk of exposure of credentials (username, password or API keys); mutual TLS, often used in service-to-service scenarios, is more complex to deploy. oAuth2.0 provides a more robust and scalable solution by decoupling authentication and authorization. It eliminates issues around credential sharing by giving users more control over their data; supports a variety of devices; and is extensible and can be developed upon.
    Citrix API Gateway: Authentication and Authorization
    NetScaler ADC is the foundation of the NetScaler API gateway solution and serves as the data plane (run-time proxy), with NetScaler Application Delivery Management (ADM) serving as the management plane. (You can use Kubernetes as the controller in a cloud-native environment.)
    NetScaler ADC provides comprehensive authentication and authorization features and supports various authentication protocols, including oAuth2.0. You can create authentication and authorization policies for fine-grain access control to your apps’ web and API resources.
    With the NetScaler API gateway solution, you don’t have to deal with implementing different authentication protocols for your app. It’s deployed in front of your app and handles authentication and authorization.
     

     
    A Traditional HMC Deployment
    NetScaler ADM service provides the control/management plane for the API gateway solution in on-prem and cloud deployments. You can carry out your configuration workflows using the intuitive UI or with APIs.
    To configure an oAuth policy to validate JWT tokens using the Citrix ADM UI, first navigate to Applications → API Gateway → Policy.
    Create a policy by selecting a deployment and upstream. Choose the ‘oAuth’ policy type and enter your details, as shown below.
     

     
    The JWKS URI is the URL where you’ll find the signature “keys” for the token issuer; these are fetched and used to validate tokens. The Issuer and Audience should match the values present in the token.
    NetScaler ADC can enhance your security posture because it supports the best practices for JWT validation outlined in RFC8725, including validation of issuer and audience. You can also limit the signature algorithms to asymmetric variants.
    If your use case requires you to validate “opaque” tokens, the introspection URL needs to be configured along the with client ID and secret. The URL is used to reach out to the authorization server for token validation. The API gateway uses the client ID and secret to identify itself with the authorization server.
    Please note, Citrix ADC uses a positive security model, so when you configure an auth policy for some API resources, you’ll configure the “No Auth” policy for the remaining API resources to skip authentication. Otherwise, access will be denied with a 401 error message.
    NetScaler ADC supports authorization policies, too. If you want to verify access privileges to a resource, you generally check the claims associated with the token using authorization policies. The policies can verify whether the required claims are present in the token received with an API request.
    In the NetScaler ADM service, navigate to Applications → API Gateway → Policy.
    Create the policy by selecting a deployment and upstream. Choose the “Authorization” policy type and enter the required claims and values expected for the selected resource endpoints. You should save any claims that you want to use here as part of your authentication configuration.
    Please note, if the API resources have authentication policies, you’ll need to create authorization policies also for those API resources. Otherwise, you’ll get a 403 error message. If you do not need authorization checks, you can create an authorization policy with empty claims.
    Deploying in Kubernetes Environment
    Apps are usually deployed as microservices in a Kubernetes environment. The configuration is applied using the Kubernetes APIs or a command line utility like ‘kubectl’ and config files. NetScaler ADC provides custom resource definitions (CRDs) for an app-specific configuration.
    Authentication and authorization policies are configured using the Auth CRD, which comes with the Citrix Ingress Controller. Typically, users apply the CRD spec, create one or more instances with values required to configure the desired authentication and authorization policies, then apply those. The following yaml file shows the use of the oAuth JWT token validation setup:
     

     
    If you save the config as auth-example.yaml file and you already have a Citrix Ingress Controller running in your cluster, you can take these steps to create the auth policies:
    # kubectl create -f auth-crd.yaml customresourcedefinition.apiextensions.k8s.io/authpolicies.citrix.com created # kubectl create -f auth-example.yaml Analytics and Observability
    NetScaler ADM has a breadth of analytics features to support observability, performance, and security monitoring. For authentication, it provides the number of authentication requests, successes, and failures, as well as the reason for failures both at the API level and for each resource individually.
     

     
    NetScaler ADC is also integrated with open-source tools like elastic search, Kibana, Prometheus, and Grafana, and you can use these to build custom reports.
     

     
    Conclusion
    There are several methods for API authentication and authorization, but oAuth2.0 is the most popular, scalable and secure. NetScaler's API gateway supports oAuth2.0 in traditional on-prem and cloud deployments, as well as in Kubernetes deployments.
    Learn more about API gateway policy creation using NetScaler ADM service and the Citrix Ingress Controller Auth CRD.
    Click Down
    Isha Khurana
    March 10, 2021
    Author: Jeff Qiu   NetScaler has offered Nitro API support for NetScaler ADC for many years, and you can find a lot of great resources online that cover how to use Nitro APIs to control NetScaler ADCs the REST API way.
    But what about the average IT guy without much web development experience (like me)? It can be tough. I spent a little bit of time playing with it and wanted to share this blog post to provide some easy-to-follow steps that will help any infrastructure admin (with some experience in C#) automate the configuration of NetScaler ADC and implement customized tools with complex logic flows.
    Part 1: Set Up Your Environment
    First, read the online documentation before you get started. Then, go to the web console of your NetScaler ADC, where you’ll find the download link to the C# SDK on the Downloads page, as shown below.
    /applications/core/interface/js/spacer.png" data-src="/monthly_2022_12/image.jpg.6d668ed6856c3aad44094408a8632f4a.jpg" data-ratio="71.64" width="737" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    SDK download page You can also download the SDK from your NetScaler ADC from the following folder, via a tool such as WinSCP:
    ./var/netscaler/gui/nitro-csharp.tgz
    Download the file and extract it. Guess what’s in the nitro-csharp.tgz file? Another ns_nitro-csharp_<codename>_XX_XX.tar file! Extract that file again. You will get the C# SDK folder, as shown below.

    /applications/core/interface/js/spacer.png" data-src="/monthly_2022_12/image.jpg.468fbefba9c1992ded67ce7c0170ae0f.jpg" data-ratio="24.86" width="1050" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    Start your adventure with the readme_start.txt file, which will explain the folder structure. In the doc folder, you will find a help file that contains the API reference. You need to have (at least) .NET 3.5 installed on your machine to use Csharp SDK.
    Please note, you will need to reference two DLLs in the lib folder (Nitro.dll and Newtonsoft.Json.dll) to build the sample code. A build command will look something like this:
    csc /r:../lib/nitro.dll;../lib/Newtonsoft.Json.dll MyFirstNitroApplication.cs
    If you have access to and are familiar with Microsoft Visual Studio, you can also reference those two DLLs from the menu Project → Add Reference → Browse.
    If you can successfully build the sample code into a .exe file, you are good to move forward.
    Part 2: Your First Nitro Application in C#
    Open MyFirstNitroApplication.cs to go through the very first sample code. At the start of the program, it creates a new instance of itself and tries to read three parameters.
    MyFirstNitroApplication config = new MyFirstNitroApplication(); config.ip = args[0]; config.username = args[1]; config.password = args[2]; After the build, the usage will look as follows:
    MyFirstNitroApplication.exe <NS_IP> <username> <password>
    Then, followed by a big try-catch from lines 45 to 88, it begins the configuration. Let’s take a segment out and have a closer look:
    //Create an instance of the virtual server class lbvserver new_lbvserver_obj = new lbvserver(); //Create a new virtual server new_lbvserver_obj.name = "MyFirstLbVServer"; new_lbvserver_obj.ipv46 = "10.102.29.88"; new_lbvserver_obj.servicetype = "HTTP"; new_lbvserver_obj.port = 80; new_lbvserver_obj.lbmethod = "ROUNDROBIN"; lbvserver.add(ns_session,new_lbvserver_obj); The code will typically start with a new object based on a certain object class. In this case, it is a lbvserver type of object. You might need to initialize some of the properties before you call the add method to create the real vServer. As shown in the example above, it will initialize the attributes needed for a load-balancing vServer object and then call the lbvserver.add() method to create the object in the session we created using the NSIP and login credentials. Proper error handling is always recommended.
    You can find examples of how to create objects and change configurations in the Sample folder. Use the structure of the very first program and rewrite everything between lines 53 and 75 with your own code.
    Here, I’ve created a real-world example of how to use Nitro API in C# to find out unbound/orphan objects in a production NetScaler ADC instance. Enjoy coding!
    Wrapping Up
    Thanks for reading, and I hope this helps you get ready to use Nitro APIs in C# for NetScaler ADC automation. Automation using a language you know, like C# in my case, is really useful when managing a NetScaler ADC! As always, if you’re looking for assistance implementing any of the code in this blog, contact our NetScaler Consulting team.
    DISCLAIMER:
    This sample code is provided to you “as is” with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.
    Isha Khurana
    Introduction
    Enterprises continue to migrate their web apps and APIs to the Cloud to better support work from home employees, fueled by the pandemic. At the same time, they still support business-critical web apps hosted On-Premises or in Private Clouds. Along with the growth in these internet-facing services, there has been growth in internet-borne threats.
    Bad actors continue to develop new ways to compromise them to support their illicit activities. Protecting applications from attack requires rapid identification of threats and launching of countermeasures. Citrix Web App and API Protection (CWAAP) service provides a consistent security posture and comprehensive protection for Monolithic applications On-Premises or microservices in the Cloud.
    Overview
    CWAAP service guards against their attempts to exfiltrate, manipulate or destroy online Enterprise web apps, APIs and data. It includes a comprehensive suite of technology to mitigate the risk to business-critical operations.
    Web Application Firewall - short for web application firewall, “WAF” origins are in protecting web sites hosted on-premises. However, in the Cloud Era the scope of WAFs are expanded to hybrid cloud or public cloud environments with broader attack surfaces to protect. Protection also extends to APIs used by Cloud-native systems to communicate between distributed functions that operate independently in containers. Also know as microservices, this form of development is more efficient in many ways than traditional monolithic architecture, yet by nature is primarily hosted in the Cloud, and subsequently, APIs are vulnerable to attack. DDOS Protection - Distributed Denial of Service (DDOS) Protection guards against internet-born attacks that seek to disrupt access to cloud services. Typically initiated by bad actors through BOT armies, DDOS attacks focus on consuming available resources to the point customer access is disrupted or denied.
    WAF Protection
    Hosted in the Cloud or on Premises Citrix WAF protects against known and unknown attacks, including application-layer and zero-day threats. It includes protections against Top 10 Web Application security risks, defined by the OWASP Foundation, at its core and expands on those with ever-growing security definitions and countermeasures from multiple threat research sources.
    Large enterprises may have hundreds or thousands of applications online that need to be secured. Therefore matching attacks, against unique web app flows to different applications at scale is a challenge. Citrix WAF automates Protection against internet-borne attacks keeping traffic at the Cloud or On-Premises edge. It detects and mitigates incessant online threats around the clock. This allows Security operations to focus more on strategic security activities and address vulnerabilities elsewhere in the infrastructure.
    Citrix WAF works on both a positive and negative attack model. The positive model identifies zero-day threats by looking for abnormal activity patterns. The negative model identifies previously documented attack signatures.
    Negative Security Model
    Injection flaws, such as SQL and LDAP injection, have been a perennial favorite among hackers, along with Cross-site scripting attacks. Other web attack protections include:
    Core
    HTML SQL Injection - provides defenses against injection of unauthorized SQL code that might break security. HTML Cross-Site Scripting - examines both the headers and the POST bodies of user requests for possible cross-site scripting attacks. Cross-Site Request Forgery (CSRF) Form Tagging - tags each web form sent by a protected website to users with a unique and unpredictable FormID and then examines the web forms returned by users to ensure that the supplied FormID is correct. Buffer Overflow Check - detects attempts to cause a buffer overflow such as URLs, cookies, or headers that are longer than the configured length. Advanced
    Cookie Consistency - examines cookies returned by users to verify that they match the cookies that the protected website set for that user. If a modified cookie is found, it is stripped from the request before the request is forwarded to the webserver. Field Consistency - examines the web forms returned by users in response to HTML requests and verifies that unauthorized changes to the structure were not made. Field Format - verifies the data that users send, including the length and type. Content-Type - ensures the Content-Type headers are either“application/x-www-form-urlencoded”, “multipart/form-data,” or “text/x-gwt-rpc”types. Any request that has any other content type designated is blocked. HTTP RFC - inspects the incoming traffic for HTTP RFC protocol compliance and drops any request with RFC violations. Deny URL - examines and blocks connections to URLs commonly accessed by hackers and malicious code. POST Body Limit - Limits the request payload (in bytes) inspected for signatures. XML
    XML SQL Injection - examines and blocks user requests with injected SQL in XML payloads. XML XSS - examines and blocks user requests with cross-site scripting attacks in XML payloads. XML Format - examines and blocks incoming requests that are not well-formed or that do not meet the specification for properly-formed XML documents. XML SOAP Fault - examines responses from your protected web services and filters out XML SOAP faults. This prevents the leaking of sensitive information to attackers. Web Service Interoperability - examines and blocks requests and responses that do not adhere to the WS-I standard and might not interact with XML application appropriately. Positive Security Model
    Citrix WAF supports a positive protection model with learning rules that build on the negative model by creating a profile of allowed traffic. Advanced heuristics analyze traffic to identify standard behavior and make recommendations for tuning of countermeasures. This helps ensure Protection against zero-day attacks that are not addressed in existing signatures.
    DDOS Management
    DDOS attacks focus on disruption through resource consumption. There are three main groups of DDOS attacks:
    Volume-based attacks - attempt to disrupt regular service by overwhelming sites with a flood of traffic. These include UDP or ICMP floods that try to exceed available bandwidth, denying legitimate user requests from ever reaching the target site. Protocol-based attacks - focus on the transport layer and take advantage of protocol operations. Packets are typically “spoofed” or sent with fake IP header information to illicit a response to consuming site resources. A typical example is a “SYN” attack. With this type of attack, the bad actor’s host, or a BOT, sends a request to establish a TCP layer session. A TCP session is ultimately required for legitimate users to establish an HTTP session to use the web service. However, the initiating host never responds to the site’s SYN ACK yet sends more SYNs, steadily consuming memory on the web service as it waits to establish TCP sessions. Application layer attacks - these attacks focus on the application layer and seek to overcome resources or take advantage of web server vulnerabilities. The attacks try to illicit, excessive site responses by manipulating protocol communication with crafted GETs or POSTs. The Citrix DDoS solution provides a holistic solution to DDOS protection buyers. It is an always-on DDoS attack management service. It features one of the world’s largest scrubbing networks with 14 POPs and 12 Tbps capacity that protects applications from large-scale volumetric DDoS attacks.
    Management
    CWAAP is configured and managed through a flexible SaaS portal. The CWAAP service portal, accessible through a browser, enables security admins to configure attack protections, monitor attack activity through a dashboard, or report on events.
    Setup
    CWAAP is setup with the help of Citrix using one of two methods:
    DNS - using DNS is the most common and easiest method. Customers direct their site A records to a Citrix CWAAP domain setup for their site. With this method, customers maintain control and can schedule a quick transition using a low TTL setting for the record. BGP - using BGP requires customers to transfer control of their pertinent routing block to Citrix. Then Citrix announces the route on behalf of the customer, and traffic to target sites without the block is directed to the CWAAP for inspection. Configuration
    CWAAP WAF policies and custom rules are configurable through the SaaS portal:
    WAF Policies - there are three primary sets of policies, and when detected, administrators can configure them to block, log, or both. Core policies are the most common types of attacks, including SQL injection, cross-site scripting, and buffer overflow. Advanced are more complex attacks using cookies or trying to take advantage of the HTTP protocol, while the last group pertains to XML-specific attacks. Signatures to identify the attacks are continuously developed by a Citrix research team and are updated automatically when published. Responder Policies - admins may configure custom rules to drop, log, or redirect connections based on specific parameters such as the hostname, source IP address, or destination port. Network Controls - admins may configure ACLs to block specific IP address ranges or traffic from specific countries. Alerts - admins may configure custom alerts when the amount of traffic within a certain interval is exceeded from a specific parameter such as the same ASN, country, or User-Agent. Trusted Sources - admins may configure an allow list of trusted sources that bypass inspection policies. Assets - admins configure the target site or sites these configured policies should apply to.
    Monitoring
    The CWAAP Portal gives Citrix admins the ability to monitor CWAAP Protections centrally. The main dashboard provides an aggregate view of site volume, including total traffic, broken down by clean traffic and mitigated traffic.
    It also includes a detailed log of attacks, including volume, duration, and countermeasures deployed.

    Summary
    Enterprises’ use of cloud services and mobile applications continues to drive the growth of cloud-native web and API traffic while maintaining some business-critical web apps On-Premises. With this growth in apps and APIs online, they are increasingly vulnerable to the persistent attacks that come with being hosted on the public internet. Citrix Web App and API Security service is constantly evolving to stay ahead of these complex attacks. It includes an advanced suite of technology based on Machine Learning and Artificial Intelligence to protect these critical Enterprise services in the Cloud and On-Premises.
    References
    Learn more at Citrix® Web App and API Protection™
    Akhil Nair
    Pre-Requisite: Customers should have a Premium NetScaler License and ADM Service to enable API Gateway
    The rise of API-driven software has seen a corresponding rise in API-related security attacks. In the last few years, the industry has seen an increase in data breaches across companies of all shapes and sizes. Notable enterprises such as Venmo, Experian, and Peloton among others have all been victims of API attacks and data breaches. This has led to the exposure of millions of personally identifiable information (PII) records of their customers, costing millions in damages and fines.
    As organizations are realizing the critical need for effective API security in their overall security posture, Citrix API Gateway is one solution that’s ready to solve the challenge. 3 simple steps can enable organizations to protect their APIs by deploying them behind the Citrix API Gateway. They are as follows:
    Onboarding the API Deploying the API Enabling Policies Onboarding the API
    To onboard your API to the Citrix API Gateway, the first step is uploading the API specification. An API specification is a high-level blueprint of how your API works structurally. Although sometimes development teams may overlook creating an API specification, it is an incredibly important step in the end to have secure applications.
    The OpenAPI Specification (OAS), previously known as Swagger, is one such standard interface for RESTful API specifications, allowing APIs to be discovered and understood by both computers and humans. An OAS specification is represented as an object in a JSON or YAML file. No need to worry if you don’t have your API spec already created. You can create one manually inside the Citrix API Gateway.
    To begin, navigate to your instance of Citrix ADM and login. Once there, follow these steps.
    Go to the sidebar and click Security >> API Gateway >> API Definitions Click Add and either upload your OAS API specification file (if you have one) OR select Create Your Definition to create one manually Now that you’ve added your API spec, it’s time to deploy your API to the gateway.
    Deploying the API
    Go to the sidebar and click Security >> API Gateway >> Deployments Click Add and fill out the details under the Deployment Basic Info Give your deployment a name and select the target API gateway (NetScaler) from the drop-down menu. Select the relevant API definition and fill out details around IP address, port, certification, and so on Next, under Upstream Services, click Add to configure your Upstream API Services (aka your back end API service) Next, Under Routing, add routes for the API Upstream Services or back-end API services that you created. Routing for API Upstream Services adds details about API routing configuration for the API Gateway to route incoming API calls to the right back end service. Enabling Policies
    The next step in the deployment process is to create policies for the API Upstream Services or back end API services.
    Go to the sidebar and click Security >> API Gateway >> Policies Click Add. Fill out a name, select a deployment and choose the appropriate upstream service Next, click Add to create various types of policies against different API resources Some useful policies include rate-limiting, authorization, WAF, Bot, header rewrite, and deny. You can also create custom rules according to your business needs. Once complete with all policies, click Save and Apply. And that’s it. You’ve successfully onboarded your API to the Citrix API Gateway. This is one step that pays dividends in the end as your APIs and applications are now more secure. Not only this helps limit your attack surface, but it will also help you gain holistic visibility into your API ecosystem (via the API Analytics feature). This allows you to monitor API performance, discover shadow and leaky APIs, monitor endpoint activity, and gain various insights on your API deployments.
    With the added level of security, rest assured knowing that the Citrix API Gateway takes care of the tedious and keeps your applications much more secure.
    Akhil Nair
    Whether you’re developing a software program or building a website, you may often find yourself, either as a front-end or back-end developer, requiring an application programming interface (API). APIs are the protocols, routines, and utilities that work behind the curtain to facilitate communication among web and mobile apps, and they’ve completely changed how we use mobile and web apps. They’re the key integration point, and you can usually find an API for almost anything such as current local weather information, Netflix content, or Google search information.
    The global API management market is expected to grow from USD 1.2 billion in 2018 to USD 5.1 billion by 2023, at a compound annual growth rate 32.9 percent. The key drivers for that include increased demand for API-led connectivity and the need for public and private APIs to accelerate digital transformation. Three significant shifts in the industry have led to this amazing growth:
    Consumer shift from single-device to multi-device usage Architecture shift from monolithic devices to microservices Infrastructure shift from on-prem to cloud Along with these shifts in the industry have come ever-increasing complexity, lack of clear visibility into API access, and challenges in terms of new and increased levels of attacks on APIs.
    In this post, we will look at the NetScaler’s API security offering. We will also examine the security issues that shadow APIs can pose to organizations and how API discovery can help eliminate the security risks associated with shadow APIs.
    NetScaler API Security
    NetScaler API security offers comprehensive protection for your APIs so that you can secure your organization’s valuable app and data assets. Because our API security is built on top of NetScaler ADC, it delivers a level of performance and security built up over two decades.
    NetScaler API security front ends API services and acts as a gateway and single point to enforce security policies on the APIs. NetScaler API security works in conjunction with NetScaler Application Delivery Management (ADM) to provide insights into API performance and to help you make more informed decisions. The API gateway provides a single point of entry for API calls, and it helps you to configure, manage, and secure API endpoints. It can perform rate limiting, authentication and authorization, content routing, and additional tasks to ensure secure, reliable access to back-end services via your APIs.
    You can use NetScaler ADM to manage your API gateway, and NetScaler API security uses machine learning in NetScaler ADM to thwart cyberattacks like excessive data exposure (OWASP API-3) and attempted account takeovers.
    Shadow APIs and API Discovery
    Agile development processes help software teams to make smaller incremental changes to code at a rapid pace, and APIs enable DevOps to focus on accelerating the pace of innovation by continuously delivering new apps and APIs. However, this speed of innovation can create silos, especially in organizations in which multiple teams are involved.
    When those shadow APIs are created and/or deployed outside of an organization’s documented publication process, when specifications are not conformed to, or when older versions of APIs are not end-of-lifed properly, they can introduce potential security risks that can lead to data loss, fraud, or abuse. Shadow APIs or deprecated APIs may not be subject to an organization’s normal security policies, and they may transmit sensitive information or confidential PII data with no security oversight. Auto API discovery, inventory, and assessment of your APIs eliminate security risks associated with shadow APIs.
    NetScaler API Discovery and Analytics
    NetScaler API security learns about APIs by onboarding API definitions from an OAS file. OAS (OpenAPI Specification) is a community-driven open specification within the OpenAPI Initiative, a Linux Foundation Collaborative Project. OAS defines a standard, programming language-agnostic interface description for REST APIs.
    The ability to onboard APIs from an OAS file dramatically speeds up the configuration of your NetScaler API security functionality. What used to be a time-consuming, manual process is simplified and automated with NetScaler ADM. It will accept new API definitions from an OAS file and lets you configure your API gateway policies and then deploy them to NetScaler ADC in a matter of minutes, enabling you to deploy new apps securely and quickly.
    Follow these steps to create an API Definition in NetScaler ADM:
    Navigate to Applications → API Gateway → API Definitions. Click Add. To Create your definition using the API Specification file, click “Upload OAS Specification” to browse and upload the API specification (Swagger 2.0 or OpenAPI 3.0). This will parse and auto-populate the required information to create your API Definition. Alternatively, you can manually input the required API information, all resource paths, and the methods to create your API Definition manually. Select Create Your Definition and specify the following required API information to create your API definition manually: Name – A name for the API definition. API Definition – A definition must include title, version, base path, and host. You can specify a domain name or IP address in the Host. API Resources – Add multiple API resources to your definition. Each resource has a path and supported method.
    /applications/core/interface/js/spacer.png" data-src="/monthly_2022_12/image.jpg.baf08a2e3916f35d2cf31346f2349c13.jpg" data-ratio="73.1" width="1000" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    Click Create. NetScaler API Discovery
    NetScaler’s integrated API discovery offering helps to make your API security more effective and simpler to deploy and makes automating and centralizing the visibility of all of your APIs easy. API discovery enables you to create an inventory of all APIs and delivers insights into API usage and security metrics.
    API discovery identifies the REST/HTTP API traffic transactions as seen by the NetScaler ADC (API Security/Gateway) data plane for the selected duration. All virtual servers and API deployments that have API traffic are displayed.
    When you select a specific virtual server or API deployment, you’ll get an inventory view of all API endpoints and methods for which the API traffic was observed with the following information:
    Method – This displays the method used in an API endpoint (for example, the GET and POST methods). Total requests – This displays the count of API requests on the API endpoint. Response statuses – This displays the count for each response status (for example, 2xx, 3xx, 4xx, and 5xx). Found in Spec – This column appears only for API deployments. Sometimes, the internal APIs that aren’t part of the API definition might receive traffic from outside. This column helps you identify whether the API endpoint and observed method are part of the API definition. This column helps you identify API resources and methods that are not present in your onboarded API definition, thus it helps you discover shadow APIs or unpublished APIs. Here you should check for the presence ofsShadow APIs. Analyze the APIs to ensure that they conform to your specifications, that they are not deployed outside of your documented publication process, and that no older versions or end-of-lifed versions improperly display. If you find shadow APIs, they can be properly mitigated before they lead to data loss, fraud, and app business logic abuse. API deployments – This displays APIs that are deployed from NetScaler ADM using an API definition. The API deployments tab discovers the API endpoints when API deployments receive API requests for the specified period. The Found in Spec column of API deployments can help you to discover Shadow APIs and mitigate them in a timely way to prevent security threats.
    /applications/core/interface/js/spacer.png" data-src="/monthly_2024_01/image.thumb.jpg.1d4355f33d3929d82f5dbb9abc5e23df.jpg" data-ratio="43.7" width="1000" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    You can also select the required API endpoint to view its detailed analytics report. The detailed analytics report provides API endpoint performance and usage data such as response time, bandwidth consumption, geo locations from where the API endpoints were accessed, and HTTP response status of API endpoints. API analytics enables visibility into API traffic and allows IT administrators to monitor API instances and endpoints served by an API gateway.

    /applications/core/interface/js/spacer.png" data-src="/monthly_2024_01/image.thumb.jpg.32dc91b68a28b358d46d397d72084dfd.jpg" data-ratio="146.77" width="511" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    Learn More
    Effective API security requires that multiple tools work in concert. NetScaler’s API security solutions can protect your most important assets from harm and help you to ensure your workforce can be productive from anywhere.
    Isha Khurana
    Digital transformation and cloud application adoption are top business imperatives, and the need to connect a growing number of apps and digital experiences is only increasing. APIs give developers easily access to apps and the ability to combine digital assets in different systems, even if those systems were never intended to interoperate.
    APIs can automate the transfer of data between different apps and systems, ensuring greater efficiency, improved reliability, and faster rollouts for innovative solutions. According to the State of API Integration Report*, 83 percent of IT specialists, whether focused on the frontend or backend, consider API integration vital for their business. This has put DevOps front and center in digital business strategy as companies seek simple, streamlined ways to develop, deploy, change, and manage apps.
    Traditional automation methods like custom scripting, direct integrations, and web services introduce more complexity, and IT teams largely rely on REST APIs to facilitate their automation journey. As a result, Bain & Company estimates, the number of companies scaling their automation will double by 2023**.
    Security is the top priority for most organizations, and there’s increased demand for secure integrations with other APIs and systems. Organizations want and need products that can ensure a frictionless API integration experience. NetScaler App Delivery and Security Service provides a simple and rich app-centric configuration model for seamless app delivery, augmented with sophisticated analytics, rich security, and self-healing capabilities.
    NetScaler App Delivery and Security Service's APIs are designed using an “outside-in” approach, simplifying the user and developer experience. From APIs, API documentation, API developer portals, and API artifacts, NetScaler App Delivery and Security Service provides simple and intuitive APIs that offer a self-service developer portal, complete documentation, a great onboarding experience, consistent and useful error messaging, code samples, Postman scripts, and a free developer tier.
    NetScaler App Delivery and Security Service's REST APIs lets you build and tailor solutions to suit your business or functional intent. This is essential in enabling integration between discrete microservices APIs. NetScaler App Delivery and Security Service APIs are well documented on NetScaler's Developer Portal using the OpenAPI standard (formerly known as Swagger) to show parameters, enable live calls, and provide the specification itself for download by developers.
    DevOps teams use a variety of tools to automate APIs and set up new environments, which allows them to treat infrastructure as code. As APIs are becoming an essential component of software development, it’s necessary for developers and programmers to manage every stage of the API lifecycle. Let’s look at how the NetScaler App Delivery and Security Service does it.
    Postman Integration
    NetScaler App Delivery and Security Service seamlessly integrates with Postman to incorporate automated testing into your CI/CD pipeline ensuring to simplify each step of building an API and streamline collaboration so you can create better APIs faster. Key benefits of NetScaler App Delivery and Security Service APIs and Postman integration include:
    API-First Development: Release reliable services to build your API before deploying code. Application Development: To eliminate dependencies and reduce time to production by having front-end and back-end teams work in parallel. Automated Testing: To automate manual tests and integrate them into your CI/CD pipeline to ensure that any code changes will not break the API in production. Exploratory Testing: To explore the APIs output data in accordance to variable inputs. Developer Onboarding: To quickly get consumers up to speed on what your API can do and how it works. Developer Portals: To enable internal and external consumers to consume APIs for app delivery and security. /applications/core/interface/js/spacer.png" data-src="/monthly_2024_01/image.thumb.jpg.c0b204d3e26b9252d00068a7eed1aac4.jpg" data-ratio="56.4" width="1000" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    Delivering an app through Postman (click image to view larger) Terraform Integration for Automating Intent
    /applications/core/interface/js/spacer.png" data-src="/monthly_2022_12/image.jpg.433cfe96f85c5ad0951b7ac79ae7379f.jpg" data-ratio="11.59" width="811" class="ipsImage ipsImage_thumbnailed" alt="image.jpg">
    To enable DevOps to implement business intent, NetScaler Application Delivery and Security Service lets DevOps teams use Terraform for automation with infrastructure as code. These APIs can be leveraged to build powerful Terraform scripts that will translate business intent into human-readable, declarative configuration files. Once you trigger these terraform configuration files, all the terraform resources (or Nitro API calls of NetScaler Application Delivery and Security Service) help you provision and integrate NetScaler ADC into your app delivery lifecycle, eliminating human errors.
    NetScaler Application Delivery and Security Service is useful in scenarios where admins want a SaaS solution that helps them manage, monitor, analyze, and troubleshoot their global hybrid multi-cloud application delivery infrastructure from a single touchpoint. The key benefits of NetScaler Application Delivery and Security Service APIs are:
    Enabling Operational Efficiency: NetScaler Application Delivery and Security Service helps and enables operational efficiency by providing an exceptionally reliable, available workflow execution engine that scales to meet your needs. Enabling DevOps Automation: Customers expect their CloudOps and DevOps teams to be able to leverage automation. NetScaler Application Delivery and Security Service APIs reduce operational overhead and free up IT and DevOps staff to focus on work that adds business value by moving the cloud management tasks to be run automatically. No Upfront Investment: Organizations can innovate without making large upfront investment in equipment and can control and power systems down to reduce costs as needed. Unlock New Use Cases: It opens the door to innovation, making it possible to unlock use cases that enable access to new customers and seamless integrations with third-party applications Increase Customer Retention and Experience (CX): Today’s users demand the ability to stitch together apps and features from different vendors. Products that integrate are more valuable to customers and get more use. Faster Time to Market: It gives you flexibility to build the frontend independent of the backend and reuse the components by focusing on core business capabilities and not the long tail. To get started with NetScaler Application Delivery and Security Service and your intent-based app delivery journey, go to your account today and access the App Delivery and Security tile for your 60-day free trial.
    Sources
    * 83 percent of IT specialists (frontend and backend developers), consider API integration vital for their business, per the State of API Integration Report.
    ** Bain & Company estimates number of companies scaling their automation will double by 2023.
    Akhil Nair
    Key Use Cases:
           
     
     
    Unified Application Security - A new config workflow that consolidates all WAF and Bot capabilities into a single pane of glass while abstracting the need to learn about how security works. End users will have access to templates such as OWASP Top-10 checks and CVE related checks. It is available in ADM Service and available in ADM on-prem starting from version 14.1 12.x Builds.
      WAF Recommendation Scanner on ADM on-prem - Available as part of the Unified Application Security workflow, users can now scan their external/internal web apps and the scanner will automatically suggest WAF checks based on the Web App’s underlying technology. Available in ADM on-prem starting from version 14.1 12.x Builds.
      API Security: API aware NetScaler as proxy - API Spec files can now be uploaded on ADCs directly to validate every endpoint and ensure that it conforms to the schema. Additionally, you can apply WAF or AAA policies and use PI expressions to apply security, authenticate endpoints or route API traffic
    Other use cases:
    Protect internal apps accessed via Gateway (SPA/Storefront) from malicious attacks - You can now protect all your applications that are behind the VPN virtual server by binding the Web App Firewall policy to the VPN virtual server.
    For example - 
    A company hosts three critical applications (SAP, Workday, and Tally) behind a VPN virtual server. 
    Create multiple profiles based on the required application. Configure the profile with the necessary security checks based on the application’s need.
    Add the app firewall policies that are applicable for each application and associate the policy with the profile.
    add appfw policy sap_policy true HTTP.REQ.URL.CONTAINS (“sap.com”) pr-basic1
    add appfw policy workday_policy true HTTP.REQ.URL.CONTAINS (“workday.com”) pr-basic2
    add appfw policy tally_policy true HTTP.REQ.URL.CONTAINS (“tally.com”) pr-basic3
    Bind the created policy to VPN vserver
    Bot related expressions - You can now use bot related expressions in your policies for routing or taking a certain action on your traffic.
    For example - 
    HTTP.REQ.BOT.IS_SUSPECTED - Returns true if the client is suspected as a BOT.
    HTTP.REQ.BOT.TYPE.EQ(<bot type>) - Returns true if the client BOT type is the same as the argument. Possible values of BOT types: GOOD, BAD, and UNKNOWN.
    Security violations display OWASP tags - In the NetScaler Console GUI, the security violations now display OWASP tags. It supports the OWASP 2017 and OWASP 2021 lists and these tags help you determine whether the violation belongs to the OWASP top 10 list.
    Create or Update API definitions from discovered API endpoints - NetScaler admins can create or update an existing API Definition from the discovered API endpoints. This removes the need for admins to wait for API Schema file from the app owners/developers
    Proxy auth support for signatures and IP Reputation - In cases where NetScaler cannot connect to the internet directly or if the customer needs an added layer of security, one can configure a proxy server for retrieving latest WAF and Bot signatures and IP Reputation feeds.
    Custom keyword support for JSON payload - SQL injection and command injection have a predefined set of keywords or patterns that they look for in the incoming requests. However, if the end user wants to add additional keywords to reduce false positives, they can leverage this feature to add custom keywords of their choice.
    CLI/API support to enable WAF signatures - You can now enable individual signatures in your NetScaler Web App Firewall through CLI commands or API calls.
    For example:
    import appfw signature DEFAULT object_name -sigRuleId 1001 9882 2000 1250 810 -Enabled ON -Action LOG BLOCK
    import appfw signature DEFAULT object_name -sigCategory web-misc -Enabled ON -Action LOG BLOCK
    Configurable payload size for inspection - Post Body Limit (Bytes) - Limits the request payload (in bytes) inspected by Web Application Firewall. 
    Default value: 20000000 Minimum value: 0 Maximum Value: 10 GB

© Cloud Software Group, Inc. All rights reserved.

×
×
  • Create New...