How can the SAML Assertion Port be changed to use 443 in CA Performance Management (NetOps Portal)?
search cancel

How can the SAML Assertion Port be changed to use 443 in CA Performance Management (NetOps Portal)?

book

Article ID: 257536

calendar_today

Updated On:

Products

DX NetOps CA Performance Management - Usage and Administration

Issue/Introduction

When SAML metadata is generated for login, the SAML assertion port is 8382. 

<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" ID="c1d4bc9c-c75a-41ba-b832-e2d85e22f0c2" entityID="IP">

    <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

        <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://IP:8382/sso/saml2/LogoutService" ResponseLocation="https://IP:8382/sso/saml2/LogoutServiceResponse"/>

        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

        <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>

        <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>

        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</md:NameIDFormat>

        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://IP:8382/sso/saml2/UserAssertionService" index="0" isDefault="true"/>

    </md:SPSSODescriptor>

</md:EntityDescriptor>

Is it possible to change it to 443 for SAML assertion login only?

Environment

DX NetOps Release : 20.2 or later

Resolution

SAML works in 2 ways:

Scenario 1:

  1. User goes to PC
  2. PC redirects user to SSO on SSO Port in DB.
  3. SSO determines SAML is enabled, so redirects user to SAML server.
  4. SAML server asks user to login
  5. After successful login, SAML an UserAssertion is sent to SSO using hostname in saml.properties and SSO Port in DB.
  6. SSO validates userassertion, checks/creates user in Portal user db and sends user back to PC with a login token cookie.

Scenario 2:

  1. User goes to some portal page the company has to log into SAML
  2. They click on a link to goto Portal.
  3. PC redirects user to SSO on SSO Port in DB.
  4. SSO determines SAML is enabled, so redirects user to SAML server.
  5. SAML validates the SAML user is still valid.
  6. After successful login, SAML an UserAssertion is sent to SSO using hostname in saml.properties and SSO Port in DB.
  7. SSO validates userassertion, checks/creates user in Portal user db and sends user back to PC with a login token cookie.
    If there is a reverse proxy involved then you need to point the SSO port to the reverse proxy port, and the hostname in saml.properties should be the reverse proxy also.

So, to configure

https://proxy:443/ -> http://NetOps Portal:8382/

Do the following

  1. set hostname in saml.properties to the proxy hostname
  2. set remote value for WebSiteScheme to https
  3. set remote value for WebSitePort to 443
  4. set remote value for WebSiteHost to proxy FQHN
  5. set remote value for WebServiceHost to proxy FQHN
  6. set remote value for SsoScheme to https
  7. Export SAML XML from SsoConfig
  8. Confirm URLs in SAML XML show https://proxy:8382/...
  9. Import the XML into IDP and rebuild partnership, and export/install new metadata.xml into NetOps Portal SSO

That should make it so that NetOps Portal will send user to https://proxy:8382/sso/... then to SAML and back.  

Also, DA will send user to https://proxy:8382/sso/... for logins to odataquery and it will use https://proxy:8382/sso/... for odata API calls directly.

You also need to import the new entity XML export from SsoConfig into IDP otherwise the IDP may still think it needs to send user to 8382.

Configuring the NetOps Portal side is not enough, the IDP needs the same info import/setup or it will send the user to wrong location.

Additional Information

You need to be on 21.2.11 or later as there is a required defect fix that allows this to work:

Features and Enhancements 22.2.11

  • Symptom:
    When the SSO Service is running on https/443 and SAML2 is being used, SSO fails to validate the SAML2 Assertion, and the user fails to log in. If the user overrides SSO Virtual Directory, some SSO URLs might be made with wrong path, as they were hard coded to use /sso.

  • Resolution:
    With this fix, the validation code now handles when the Assertion is coming in with https/443 or https/no port. Both are acceptable. The various places NetOps Portal generates SSO URLs now use the SSO Virtual Directory setting in the SsoConfig tool.

    (21.2.11, DE482680)
Powered by Wolken Software