Cisco APIC Security Configuration Guide, Release 6.2(x)

PDF

Cisco APIC Security Configuration Guide, Release 6.2(x)

SAML authentication

Updated: April 17, 2026

Want to summarize with AI?

Log in

Explains an XML-based authentication protocol that enables single sign-on access across multiple Cisco collaboration applications through trusted identity providers.

SAML authentication is an XML-based open standard authentication protocol that

  • enables administrators to access a defined set of Cisco collaboration applications seamlessly after signing into one of those applications

  • describes the exchange of security related information between trusted business partners, and

  • enables exchange of security authentication information between an Identity Provider (IdP) and a service provider.

SAML SSO implementation details

SAML SSO uses the SAML 2.0 protocol to offer cross-domain and cross-product single sign-on for Cisco collaboration solutions. SAML 2.0 enables SSO across Cisco applications and enables federation between Cisco applications and an IdP. SAML 2.0 allows Cisco administrative users to access secure web domains to exchange user authentication and authorization data, between an IdP and a Service Provider while maintaining high security levels. The feature provides secure mechanisms to use common credentials and relevant information across various applications.

The authorization for SAML SSO Admin access is based on Role-Based Access Control (RBAC) configured locally on Cisco collaboration applications.

SAML SSO establishes a Circle of Trust (CoT) by exchanging metadata and certificates as part of the provisioning process between the IdP and the Service Provider. The Service Provider trusts the IdP's user information to provide access to the various services or applications.

Note

Service providers are no longer involved in authentication. SAML 2.0 delegates authentication away from the service providers and to the IdPs.

The client authenticates against the IdP, and the IdP grants an Assertion to the client. The client presents the Assertion to the Service Provider. Since there is a CoT established, the Service Provider trusts the Assertion and grants access to the client.

Enabling SAML SSO provides these advantages:

  • It reduces password fatigue by removing the need for entering different user name and password combinations.

  • It transfers the authentication from your system that hosts the applications to a third party system. Using SAML SSO, you can create a circle of trust between an IdP and a service provider. The service provider trusts and relies on the IdP to authenticate the users.

  • It protects and secures authentication information. It provides encryption functions to protect authentication information passed between the IdP, service provider, and user. SAML SSO can also hide authentication messages passed between the IdP and the service provider from any external user.

  • It improves productivity because you spend less time re-entering credentials for the same identity.

  • It reduces costs as fewer help desk calls are made for password reset, thereby leading to more savings.

Basic elements of SAML

Understanding the basic elements of SAML helps in implementing and managing SAML-based authentication systems effectively.

SAML authentication involves these basic elements:

  • Client (the user's client): This is a browser-based client or a client that can leverage a browser instance for authentication. For example, a system administrator's browser.

  • Service provider: This is the application or service that the client is trying to access.

  • An Identity Provider (IdP) server: This is the entity that authenticates user credentials and issues SAML Assertions.

  • Lightweight Directory Access Protocol (LDAP) users: These users are integrated with an LDAP directory, for example Microsoft Active Directory or OpenLDAP. Non-LDAP users reside locally on the Unified Communications server.

  • SAML Assertion: It consists of pieces of security information that are transferred from IdPs to the service provider for user authentication. An assertion is an XML document that contains trusted statements about a subject including, for example, a username and privileges. SAML assertions are usually digitally signed to ensure their authenticity.

  • SAML Request: This is an authentication request that is generated by a Unified Communications application. To authenticate the LDAP user, Unified Communications application delegates an authentication request to the IdP.

  • Circle of Trust (CoT): It consists of the various service providers that share and authenticate against one IdP in common.

  • Metadata: This is an XML file generated by an ACI application as well as an IdP. The exchange of SAML metadata builds a trust relationship between the IdP and the service provider.

  • Assertion Consumer Service (ACS) URL: This URL instructs the IdPs where to post assertions. The ACS URL tells the IdP to post the final SAML response to a particular URL.

    For the 6.2(2) release or earlier, APIC uses the ACS URL with the query parameter. https://<APIC-hostname>/api/aaaLoginSSO.json?name=<SAML-domain-name>

    For the 6.2(3) release and later, APIC uses the path-based ACS URL. https://<APIC-hostname>/api/SAML/ssologin/<SAML-domain-name>. See SAML ACS URL Formats.

Note

All in-scope services requiring authentication use SAML 2.0 as the SSO mechanism.

Supported IdPs and SAML components

This reference provides information about supported Identity Providers and SAML components for APIC SAML SSO configuration. Identity Provider (IdP) is an authentication module that creates, maintains, and manages identity information for users, systems, or services and also provides authentication to other applications and service providers within a distributed network.

Supported IdPs

With SAML SSO, IdPs provide authentication options based on the user role or log in options for each of the Cisco collaboration applications. The IdPs store and validate the user credentials and generate a SAML response that allows the user to access the service provider protected resources.

DUO Single Sign-On (DUO SSO) is supported as a SAML 2.0 Identity Provider beginning with the Cisco APIC release 6.2(3).

  • APIC treats DUO SSO as a standard SAML Identity Provider. No DUO-specific APIC configuration option is required.

Note

You must be familiar with your IdP service, and ensure that it is currently installed and operational.

The APIC SAML SSO feature has been tested with these IdPs:

SAML components

A SAML SSO solution is based on a particular combination of assertions, protocols, bindings, and profiles. The various assertions are exchanged among applications and sites using the protocols and bindings, and those assertions authenticate the users among sites. The SAML components are as follows:

  • SAML Assertion: It defines the structure and content of the information that is transferred from IdPs to service providers. It consists of packets of security information and contains statements that service providers use for various levels of access-control decisions.SAML SSO provides these types of statements:

    • Authentication statements- These statements assert to the service provider about the method of authentication that occurs between the IdP and the browser at a particular time.

    • Attribute statements- These statements assert about certain attributes (name-value pairs) that are associated with the user. The attribute assertions contain specific information about the user. The service providers use attributes to make access-control decisions.

  • SAML protocol: A SAML protocol defines how the SAML requests for and gets assertions. This protocol is responsible for the SAML request and response elements that consist of certain SAML elements or assertions. The SAML 2.0 contains these protocols:

    • Assertion Query and Request Protocol

    • Authentication Request Protocol

  • SAML binding: A SAML binding specifies the mapping of SAML assertion and/or protocol message exchanges with standard messaging formats or communication protocols like SOAP exchanges. ACI supports these SAML 2.0 bindings:

    • HTTP Redirect (GET) Binding

    • HTTP POST Binding

  • SAML profile: A SAML profile provides a detailed description of the combination of SAML assertions, protocols, and bindings to support well-defined use cases.

NTP setup

In SAML SSO, Network Time Protocol (NTP) enables clock synchronization between the APIC and IdP. SAML is a time sensitive protocol and the IdP determines the time-based validity of a SAML assertion. If the IdP and the APIC clocks are not synchronized, the assertion becomes invalid and stops the SAML SSO feature. The maximum allowed time difference between the IdP and the APIC is 3 seconds.

Note

For SAML SSO to work, you must install the correct NTP setup and make sure that the time difference between the IdP and the APIC does not exceed 3 seconds. If IdP and APIC clocks are not synchronized, the user will be redirected back to the APIC's login page even after successful authentication on IdP.

DNS setup

Domain Name System (DNS) enables the mapping of host names and network services to IP addresses within a network or networks. DNS server(s) deployed within a network provide a database that maps network services to hostnames and, in turn, hostnames to IP addresses. Devices on the network can query the DNS server and receive IP addresses for other devices in the network, thereby facilitating communication between network devices.

In summary, APIC and Idp should be able to resolve each other's fully qualified domain names to IP addresses and should be resolvable by the client.

Certificate authority

Cisco recommends using server certificates that are signed by one of these types of Certificate Authority (CA):

  • Public CA—A third-party company verifies the server identity and issues a trusted certificate.

  • Private CA—You create and manage a local CA and issue trusted certificates.

The signing process varies for each product and can vary between server versions. It is beyond the scope of this document to provide detailed steps for every version of each server. Refer the appropriate server documentation for detailed instructions on how to GET certificates signed by a CA.

If you GET server certificates signed by a public CA, the public CA should already have a root certificate present in the trust store on the client computer. In this case, you do not need to import root certificates on the client computers. You should import root certificates if the certificates are signed by a CA that does not already exist in the trust store, such as a private CA. In SAML SSO, the IdP and service providers must have CA signed certificates with the correct domains in the CN or SAN. If the correct CA certificates are not validated, the browser issues a pop up warning.

If the APIC's trust store does not include the root certificate of the IdP, a new certificate authority should be created. This Certificate Authority should be used later while configuring the SAML Provider on APIC.

Configure APIC for SAML access

Configure SAML authentication to provide secure, centralized access control for Cisco APIC GUI users through an external identity provider.

Note

SAML-based authentication is only for the Cisco APIC GUI and not for the CLI or REST API. Also, SAML is not applicable for leaf switches and spine switches. You cannot configure SAML configuration using the Cisco APIC CLI.

Before you begin

  • The Cisco Application Centric Infrastructure (ACI) fabric is installed, Application Policy Infrastructure Controllers (APICs) are online, and the Cisco APIC cluster is formed and healthy.

  • The SAML server host name or IP address, and the IdP's metadata URL are available.

  • The Cisco APIC management endpoint group is available.

  • Set up the following:

    • Time synchronization and NTP

    • A DNS service policy to connect with the DNS providers

    • A custom certificate for Cisco ACI HTTPS access

    For more information, see the Cisco APIC Basic Configuration Guide.

Procedure

  1. In the Cisco APIC GUI, create the SAML provider.

    To create a provider, see Create a provider.

  2. Create the Login Domain for SAML.

    For the detailed procedure, see Create login domain using the GUI.

SAML authentication is configured for the Cisco APIC GUI, enabling users to log in using their external identity provider credentials.

Configure DUO SSO for APIC SAML Access

Duo SSO acts as a SAML proxy. It is the SAML IdP to APIC and a SAML SP to an upstream IdP. For example, Okta, Ping Identity, or AD FS. APIC communicates only with Duo.

Follow these steps to configure DUO SSO for APIC SAML access.

Before you begin

Have your APIC Entity ID and Assertion Consumer Service (ACS) URL available.

Procedure

  1. In the Duo Admin Panel, configure Single Sign-On and add the external authentication source that Duo will use. Record the Duo SSO Entity ID and Assertion Consumer Service (ACS) URL and provide them to the upstream identity provider, such as Okta, Ping Identity, or AD FS.

  2. In Duo, provide the upstream SAML IdP’s Entity ID, Single Sign-On URL, and certificate.

  3. Add a Generic SAML Service Provider - Single Sign-On application on DUO for Cisco APIC.

  4. Record the Duo application’s metadata URL. Use this URL as the IdP metadata URL when creating the SAML provider in APIC.

  5. In the Duo application, enter the APIC Entity ID and ACS URL. For more information on ACS URLs, see SAML ACS URL Formats. For an APIC cluster, add an ACS URL for every APIC that users can access.

  6. Configure the SAML response. Select the appropriate NameID value, use SHA-256 signing, sign the response and assertion as required by the APIC SAML provider settings, and map the Email and CiscoAvPair attributes into the SAML response.

  7. Under Applications > SSO Settings, add routing rules that direct the applicable users to the intended external authentication source.

  8. In APIC, create the Duo SAML provider, and associate the provider with the SAML login domain by following Configuring APIC for SAML Access.

  9. Test the login and verify that Duo authentication completes successfully, and APIC assigns the roles provided in CiscoAvPair.

What to do next

Review authentication logs in Duo and APIC to ensure successful integration. Update routing rules or mapped attributes as needed for ongoing maintenance.

SAML ACS URL Formats

Beginning with Cisco APIC release 6.2(3), APIC supports a path-based SAML ACS URL in addition to the existing query-parameter URL.

Existing (query-parameter) format: https://<APIC-hostname>/api/aaaLoginSSO.json?name=<saml-domain-name>.

Path-based format added in release 6.2(3): https://<APIC-hostname>/api/saml/ssologin/<saml-domain-name>.

Beginning with Release 6.2(3), APIC advertises the path-based ACS URL as the AssertionConsumerServiceURL in the SAML authentication request for all identity providers. The query-parameter ACS URL remains a registered (accepted) endpoint on the APICfor backward compatibility, but it is no longer the URL advertised in the authentication request. Configure the path-based ACS URL as the ACS URL on each identity provider (Okta, Ping Identity, AD FS, and Duo).

For Okta, configure the path-based URL as the primary Single Sign-On URL or add it to the Requestable SSO URLs list. Okta does not accept a query or fragment parameter in the Requestable SSO URLs list, so the query-parameter URL cannot be used there.

Before upgrading the APIC cluster to release 6.2(3) or later, we strongly recommend adding the path-based ACS URLs to the IdP while retaining the existing query parameter-based URLs. This ensures that authentication continues to work both before and after the upgrade.

Configure SAML in APIC using REST API

This task enables SAML authentication in APIC through REST API configuration, allowing integration with external identity providers for centralized user authentication and authorization management.

SAML (Security Assertion Markup Language) authentication in APIC provides single sign-on capabilities and centralized user management. This configuration requires creating both a SAML provider and a corresponding login domain with the appropriate authentication method.

Procedure

  1. Create a SAML provider using the REST API.

    Example:

    <aaaSamlProvider name="auth.pingone.asia"
  dn="uni/userext/samlext/samlprovider-auth.pingone.asia"
  entityId="https://192.168.32.1/api/aaaLoginSSO.json"
  spEntityId="https://apic.host.com"
  guiBannerMessage="" idP="ping identity"
  metadataUrl="https://auth.pingone.com/c5f09515-6ce4-4776-a770-3d2ad98f078e/
    saml20/metadata/9a0cd2a5-daf6-40dd-9004-c562221fc6e2"
  monitorServer="disabled" retries="1" timeout="5" tp="pingonecert"
  wantAssertionsEncrypted="no" wantAssertionsSigned="yes" wantRequestsSigned="yes"
  wantResponseSigned="yes" sigAlg="SIG_RSA_SHA256"
status="created,modified" />
    Note

    The metadataUrl value has a line break for readability. However, do not include a line break in the actual value.

  2. Create a login domain with authentication using CiscoAVPair.

    Example:

    <aaaUserEp dn="uni/userext" status="created,modified">
    <aaaLoginDomain dn="uni/userext/logindomain-TestSAML"
      name="TestSAML" status="created,modified">
        <aaaDomainAuth dn="uni/userext/logindomain-TestSAML/domainauth"
          providerGroup="TestSAML" realm="saml" realmSubType="default"
          status="created,modified"/>
    </aaaLoginDomain>
    <aaaSamlEp rn="samlext" status="modified">
        <aaaSamlProviderGroup dn="uni/userext/samlext/samlprovidergroup-TestSAML"
          name="TestSAML" authChoice="CiscoAVPair" status="created,modified">
            <aaaProviderRef dn="uni/userext/samlext/samlprovider-auth.pingone.asia"
              name="auth.pingone.asia" order="1" status="created,modified"/>
        </aaaSamlProviderGroup>
    </aaaSamlEp>
</aaaUserEp>

  3. Alternatively, create a login domain with authentication using Group Map.

    Example:

    <aaaUserEp dn="uni/userext" status="created,modified">
    <aaaLoginDomain dn="uni/userext/logindomain-TestSAML" name="TestSAML"
      status="created,modified">
        <aaaDomainAuth dn="uni/userext/logindomain-TestSAML/domainauth"
          providerGroup="TestSAML" realm="saml" realmSubType="default"
          status="created,modified"/>
    </aaaLoginDomain>
    <aaaSamlEp rn="samlext" status="modified">
        <aaaSamlProviderGroup dn="uni/userext/samlext/samlprovidergroup-TestSAML"
          name="TestSAML" authChoice="LdapGroupMap" groupAttribute="memberOf"
          status="created,modified">
            <aaaUserGroupMapRule name="AdminRule"
              userGroup="CN=Domain Admins,CN=Users,DC=insaaadev,DC=net"
              status="created,modified">
                <aaaUserDomain name="all" rn="userdomain-all" status="created,modified">
                    <aaaUserRole name="fabric-admin" privType="writePriv"
                      rn="role-fabric-admin" status="created,modified"/>
                </aaaUserDomain>
                <aaaUserDomain name="mgmt" rn="userdomain-mgmt" status="created,modified">
                    <aaaUserRole name="access-admin" privType="writePriv"
                      rn="role-access-admin" status="created,modified"/>
                    <aaaUserRole name="nw-svc-policy" privType="writePriv"
                      rn="role-nw-svc-policy" status="created,modified"/>
                </aaaUserDomain>
            </aaaUserGroupMapRule>
            <aaaUserGroupMapRule name="EmpRule"
              userGroup="CN=Employee,CN=Users,DC=insaaadev,DC=net"
              status="created,modified">
                <aaaUserDomain name="mgmt" rn="userdomain-mgmt" status="created,modified">
                    <aaaUserRole name="ops" privType="writePriv" rn="role-ops"
                      status="created,modified"/>
                </aaaUserDomain>
            </aaaUserGroupMapRule>
            <aaaProviderRef dn="uni/userext/samlext/samlprovider-auth.pingone.asia"
              name="auth.pingone.asia" order="1" status="created,modified"/>
        </aaaSamlProviderGroup>
    </aaaSamlEp>
</aaaUserEp>

SAML authentication is successfully configured in APIC with the specified provider and login domain. Users can now authenticate using the configured SAML identity provider with either CiscoAVPair or Group Map authorization method.

Set up a SAML application in Okta

Set up SAML authentication integration between Okta and APIC to enable single sign-on capabilities for users.

To configure SAML in Okta, log in to your Okta organization as a user with administrative privileges.

Note

If you don't have an Okta organization, you can create a free Okta at:

https://www.okta.com/start-with-okta/

Procedure

  1. In the Admin panel in Okta, navigate to Admin Console > Applications and Resources > Applications.

  2. Select Create App Integration, and perform the following actions:

    1. In the Create New App Integration dialog box, select the SAML 2.0 radio button, then click Next.
    2. In the General Settings box, enter Example SAML Application in the App name field, then click the green Next button.
    3. In the Configure SAML > SAML Settings field, paste your SAML URL into the Single sign on URL, Recipient URL, and Destination URL fields. This can be done together by toggling the checkbox.

      The fields should be of the below format:

      • For the 6.2(2) release or earlier: 
        https://<APIC-hostname>/api/aaaLoginSSO.json?name=<saml-login-domain-name>
        For the 6.2(3) release or later: 
        https://<APIC-hostname>/api/saml/ssologin/<saml-domain-name>
      • Audience URI (SP Entity ID): This is the stable identifying URL for all APIC(s) in the cluster. This identifier represents the APIC and can be any string, although the ACS URL is commonly used. Configure the same value on both APIC and identity provider (IdP). 
        https://<apic-hostname>/<saml-domain-name>

      • Name ID Format: Unspecified

      • Response: Signed

      • Assertion Signature: Signed

      • Signature Algorithm: RSA-SHA256 by default

      • DigestAlgorithm: SHA256 by default

      • Assertion Encryption: Enable to encrypt the SAML assertion sent by Okta. Requires uploading the APIC's public encryption certificate on Okta. Disabled by default

      • Enable Single Logout: Disabled

      • Signed requests: Enable to validate the signature on SAML authentication requests sent by APIC. Requires uploading the APIC's public signing certificate on Okta. Disabled by default

      • Other requestable SSO URLs to configure cluster of APICs:

        • https://<APIC1_hostname>/api/saml/ssologin/<saml-login-domain-name>
        • https://<APIC2_hostname>/api/saml/ssologin/<saml-login-domain-name>
        • https://<APIC3_hostname>/api/saml/ssologin/<saml-login-domain-name>

      • Authentication context class: PasswordProtectedTransport

      • SAML Issuer ID: http://www.okta.com/${org.externalKey}

    4. Once the application is created, navigate to Sign on > Attribute Statements > Show legacy configuration and click on Edit, besides the Profile attribute statements.
    5. In the Attribute statements section, configure required values. CiscoAvpair to the corresponding Okta user profile fields and click Next.

      A minimum requirement is:

      Name: Email

      Expression: user.profile.email

      For user group based authorization, add groups:

      Name: groups (same value as what you configure in the APIC login domain)

      Expression: user.getGroups({'group.profile.name':'<regex>'}).![profilename]

      When the user group names are apic_usergroup_1, apic_usergroup_2 and so on, the expression should be user.getGroups({'group.profile.name':'apic_usergroup.*'}).![profile.name]`

      For Cisco AVpair based authorization, add **CiscoAVpair**:

      Name: CiscoAVpair

      Expression: user.profile.ciscoAVPair

      Note

      Check Okta's official documentation for details regarding the expression syntax.

    6. Configure Ciscoavpair separately, as a custom SAML attribute to provide APIC RBAC information.

      For more information on CiscoAvpair, see AV Pair on the External Authentication Server.

  3. On the same Sign On tab, within Sign on Methods > SAML 2.0, the metadata URL is visible. You will return to this page later to copy the Identity Provider metadata link for your SAML configuration.

The SAML application is created in Okta with the necessary configuration for APIC integration. The Identity Provider metadata link is available for use in your SAML configuration.

Set up a relying party trust in AD FS

Set up a relying party trust in AD FS to establish a secure authentication mechanism between Active Directory Federation Services and APIC using SAML protocols.

A relying party trust must be configured in AD FS Management Console to enable SAML-based single sign-on authentication for APIC users.

Procedure

  1. Add relying party trust:

    1. Login to AD FS Management Console on your AD FS server, Navigate to ADFS > Trust Relationships > Relying Party Trusts and right-click on Add Relying Party Trust and click Start.
    2. Choose Enter data about the relying party manually or Import data about relying party from a file (skip the steps d, e, f and g) by importing the metadata file generated using the Download SAML Metadata option available on the corresponding login domain setup in APIC.
    3. Enter your preferred Display Name for the relying party trust and click Next.
    4. Choose AD FS Profile and click Next.
    5. Click Next again.
    6. For the 6.2(2) release and before, select Enable support for the SAML 2.0 Web SSO Protocol and enter Relying party SAML2.0 SSO service URL as https://<APIC_hostname>/api/aaaLoginSSO.json?name=<Login_domain_name> and click Next.

      For the 6.2(3) release and later, Select Enable support for the SAML 2.0 Web SSO Protocol and enter Relying party SAML2.0 SSO service URL as https://<APIC_hostname>/api/SAML/ssologin/<Login_domain_name> and click Next.

    7. Enter the Relying party trust identifier – https://<APIC_hostname>/api/aaaLoginSSO.json
    8. Choose I do not want to configure multi-factor authentication settings for this relying party trust at this time and click Next.
    9. Choose Permit all users to access this relying party and click Next.
    10. Select Open the Edit Claim rules dialog for this relying party trust when the wizard closes and click Close.

  2. Add the following Claim rules:

    1. Send LDAP Attributes as claims:

      • In the Edit Claim Rules window, click Add Rule.

      • Select the Claim Rule Template as Send LDAP attributes as Claims and click Next.

      • Enter a Rule_Name and select Active Directory as the Attribute Store.

      • Select the reserved User Attribute for storing CiscoAvpair (For Ex: Department) as LDAP attribute type and map it to Outgoing Claim Manually Type as CiscoAvpair.

      • Select E-Mail-Addresses on LDAP Attribute and map it to the Outgoing Claim Type E-mail Address and click Finish.

    2. Transform an Incoming Claim:

      • Click Add Rule again in the Edit Claim Rules window, and select Transform an Incoming Claim as Claim Rule Template and click Next.

      • Select E-Mail Address as the Incoming claim type.

      • Select Name ID as Outgoing claim type.

      • Select Transient Identifier as Outgoing name ID format.

  3. To add a cluster of APICs, one can either setup multiple Relying Party Trusts or setup single Relying Party Trust and add multiple Relying Party Identifiers and SAML Assertion Consumer Endpoints to it.

    1. Adding other APICs in a cluster with same relying party trusts created above.

      1. Navigate to ADFS Management Console > ADFS > Trust Relationships > Relying Party Trusts and right-click on CiscoAPIC > Properties.

      2. Click on Identifiers tab and add other APICs in cluster as: https://<APIC2_hostname>/api/aaaLoginSSO.json, https://<APIC3_hostname>/api/aaaLoginSSO.json

        For the 6.2(3) release and later, click on Identifiers tab and add other APICs in cluster as: https://<APIC2_hostname>/api/SAML/ssologin/<Login_domain_name>, https://<APIC3_hostname>/api/SAML/ssologin/<Login_domain_name>

      3. Click on Endpoints tab and Other two APICs by clicking on Add SAML. Add SAML Post Binding, Index as 1 and enter trusted URL as: https://<APIC2_hostname>/api/aaaLoginSSO.json?name=<Login_domain_name>

        For 6.2(3) release and later, Add SAML Post Binding, Index as 1 and enter trusted URL as: https://<APIC2_hostname>/api/SAML/ssologin/<Login_domain_name>

        , and Add SAML Post Binding as: https://<APIC3_hostname>/api/aaaLoginSSO.json?name=<Login_domain_name>

        For the 6.2(3) release and later, Add SAML Post Binding as: https://APIC3_hostname>/api/SAML/ssologin/<Login_domain_name>.

  4. Message and Assertion need to be signed in ADFS from powershell in ADFS server. For Signing Message and Assertion in ADFS Server:

    1. Open Windows Powershell (should be run as Administrator) and execute the below command:
    2. Set-AdfsRelyingPartyTrust -TargetName RelyingpartytrustnameOfCiscoAPIC -SamlResponseSignature MessageAndAssertion.

The relying party trust is successfully configured in AD FS, enabling SAML-based authentication between AD FS and APIC with proper claim rules and message signing.