Not able login userapp aftr i enter LBDNS in configupdate.sh

Hi,

When I configure ./configupdate.sh and put load balancer DNS in Authentication and SSO clients tabs, i'm able to get the login page but when i enter userapp admin credentials i'm not able to login. and i don't get any errors

It works fine when I configure ./configupdate.sh and put localhost DNS in Authentication and SSO clients tabs.

I have also updated Load balancer DNS on User app and role resource driver.


Userapp is running on base version 4.5


Please let me know what i'm missing.

Thanks,
Sushant
  • On 7/19/2017 10:14 AM, sushantcap wrote:
    >
    > Hi,
    >
    > When I configure ./configupdate.sh and put load balancer DNS in
    > Authentication and SSO clients tabs, i'm able to get the login page but
    > when i enter userapp admin credentials i'm not able to login. and i
    > don't get any errors
    >
    > It works fine when I configure ./configupdate.sh and put localhost DNS
    > in Authentication and SSO clients tabs.
    >
    > I have also updated Load balancer DNS on User app and role resource
    > driver.
    >
    >
    > Userapp is running on base version 4.5


    OSP is super picky about DNS names.

    You need to configure all the certs, and DNS and everything to match,
    completely, down to the port.

    So if you change the DNS name, you need to fix the certs and make sure
    all references are all the same.


  • On 7/19/17 10:31 AM, Geoffrey Carman wrote:
    > On 7/19/2017 10:14 AM, sushantcap wrote:
    >>
    >> Hi,
    >>
    >> When I configure ./configupdate.sh and put load balancer DNS in
    >> Authentication and SSO clients tabs, i'm able to get the login page but
    >> when i enter userapp admin credentials i'm not able to login. and i
    >> don't get any errors
    >>
    >> It works fine when I configure ./configupdate.sh and put localhost DNS
    >> in Authentication and SSO clients tabs.
    >>
    >> I have also updated Load balancer DNS on User app and role resource
    >> driver.
    >>
    >>
    >> Userapp is running on base version 4.5

    >
    > OSP is super picky about DNS names.
    >
    > You need to configure all the certs, and DNS and everything to match,
    > completely, down to the port.
    >
    > So if you change the DNS name, you need to fix the certs and make sure
    > all references are all the same.
    >
    >

    Greetings,
    It is not that OSP is "super picky", it is that OSP adhering to the
    spec. During the install of OSP you outlined the URL (IP address or
    DNS) that one would utilize to access it. This value is then used as
    part of creating the certificate that OSP uses.

    Therefore, if you are now going to be using a different means to
    access (IP or different dns value), then you have regenerate the
    certificate that OSP is using and change all of the mappings in the SSO
    Client Tab.



    --
    Sincerely,
    Steven Williams
    Principal Enterprise Architect
    Micro Focus
  • sushantcap;2462075 wrote:
    Hi,

    When I configure ./configupdate.sh and put load balancer DNS in Authentication and SSO clients tabs, i'm able to get the login page but when i enter userapp admin credentials i'm not able to login. and i don't get any errors

    It works fine when I configure ./configupdate.sh and put localhost DNS in Authentication and SSO clients tabs.

    I have also updated Load balancer DNS on User app and role resource driver.


    Userapp is running on base version 4.5


    Please let me know what i'm missing.

    Thanks,
    Sushant


    Dear Sushant,

    Kindly refer our documentation on this context: #https://www.netiq.com/documentation/identity-manager-46/setup/data/b1hiq223.html (step 8 to 12) would help us to double-check on this configurations along with below other suggestions .
  • On 19-7-2017 16:44, Steven Williams wrote:
    > On 7/19/17 10:31 AM, Geoffrey Carman wrote:
    >> On 7/19/2017 10:14 AM, sushantcap wrote:
    >>>
    >>> ...

    >>
    >> OSP is super picky about DNS names.
    >>
    >> You need to configure all the certs, and DNS and everything to match,
    >> completely, down to the port.
    >>
    >> So if you change the DNS name, you need to fix the certs and make sure
    >> all references are all the same.
    >>
    >>

    > Greetings,
    > It is not that OSP is "super picky", it is that OSP adhering to the
    > spec. During the install of OSP you outlined the URL (IP address or
    > DNS) that one would utilize to access it. This value is then used as
    > part of creating the certificate that OSP uses.
    >
    > Therefore, if you are now going to be using a different means to
    > access (IP or different dns value), then you have regenerate the
    > certificate that OSP is using and change all of the mappings in the SSO
    > Client Tab.
    >

    Could you please explain why the subject of the certificate in the
    osp.jks matters? My understanding is that the key pair in the osp.jks
    keystore is only used by the OSP itself to:
    - digitally sign the oauth2 tokens it generates
    - verify the digital signature on oauth2 tokens in incoming requests
    (typically when an IdM component calls the OSP's
    /osp/a/idm/auth/oauth2/getattributes endpoint to validate an oauth2
    access token and find out which user it belongs to).

    When I swap the certificate in my osp.jks keystore with a certificate
    that has a dummy subject name and then restart all IdM components,
    everything still works fine.

    So to my knowledge (please correct me if I'm wrong):
    - the subject of the self-signed certificate in the osp.jks keystore is
    irrelevant and doesn't have to match any particular DNS name.
    - the self-signed certificate in the osp.jks keystore does not have to
    be trusted by any IdM components (e.g. no need to import it into cacerts
    files).
  • Steven Williams wrote:

    > It is not that OSP is "super picky", it is that OSP adhering to the spec.
    > During the install of OSP you outlined the URL (IP address or DNS) that one
    > would utilize to access it. This value is then used as part of creating the
    > certificate that OSP uses.
    >
    > Therefore, if you are now going to be using a different means to access (IP
    > or different dns value), then you have regenerate the certificate that OSP is
    > using and change all of the mappings in the SSO Client Tab.


    Certificates allow for subject alternative names as long as I can think and
    it's a major pain not to be able to use different URLs to log in to the IDM
    apps.
    May I suggest you enhance configupdate to supprot multiple URLs in the next
    release? Add all of them as SANs to cert and a constant source of complains
    would be gone forever...

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • On 7/20/17 4:16 AM, Lothar Haeger wrote:
    > Steven Williams wrote:
    >
    >> It is not that OSP is "super picky", it is that OSP adhering to the spec.
    >> During the install of OSP you outlined the URL (IP address or DNS) that one
    >> would utilize to access it. This value is then used as part of creating the
    >> certificate that OSP uses.
    >>
    >> Therefore, if you are now going to be using a different means to access (IP
    >> or different dns value), then you have regenerate the certificate that OSP is
    >> using and change all of the mappings in the SSO Client Tab.

    >
    > Certificates allow for subject alternative names as long as I can think and
    > it's a major pain not to be able to use different URLs to log in to the IDM
    > apps.
    > May I suggest you enhance configupdate to supprot multiple URLs in the next
    > release? Add all of them as SANs to cert and a constant source of complains
    > would be gone forever...
    >

    Greetings,
    Supporting multiple URLS is not a configupdate or Identity Apps
    "issue". OSP is adhering to the spec regarding single URLs

    --
    Sincerely,
    Steven Williams
    Principal Enterprise Architect
    Micro Focus
  • >> Therefore, if you are now going to be using a different means to
    >> access (IP or different dns value), then you have regenerate the
    >> certificate that OSP is using and change all of the mappings in the
    >> SSO Client Tab.
    >>

    > Could you please explain why the subject of the certificate in the
    > osp.jks matters? My understanding is that the key pair in the osp.jks
    > keystore is only used by the OSP itself to:
    > - digitally sign the oauth2 tokens it generates
    > - verify the digital signature on oauth2 tokens in incoming requests
    > (typically when an IdM component calls the OSP's
    > /osp/a/idm/auth/oauth2/getattributes endpoint to validate an oauth2
    > access token and find out which user it belongs to).
    >
    > When I swap the certificate in my osp.jks keystore with a certificate
    > that has a dummy subject name and then restart all IdM components,
    > everything still works fine.


    That is an interesting test. I never thought to try that one. :)

    > So to my knowledge (please correct me if I'm wrong):
    > - the subject of the self-signed certificate in the osp.jks keystore is
    > irrelevant and doesn't have to match any particular DNS name.
    > - the self-signed certificate in the osp.jks keystore does not have to
    > be trusted by any IdM components (e.g. no need to import it into cacerts
    > files).


    The certificate of the Tomcat server is the one that matters the most I
    think. The cert has to match the DNS name.

    You are right that the OSP cert is for SAML if used. The Tomcat cert is
    the one that really matters.


  • >> Therefore, if you are now going to be using a different means to
    >> access (IP or different dns value), then you have regenerate the
    >> certificate that OSP is using and change all of the mappings in the
    >> SSO Client Tab.
    >>

    > Could you please explain why the subject of the certificate in the
    > osp.jks matters? My understanding is that the key pair in the osp.jks
    > keystore is only used by the OSP itself to:
    > - digitally sign the oauth2 tokens it generates
    > - verify the digital signature on oauth2 tokens in incoming requests
    > (typically when an IdM component calls the OSP's
    > /osp/a/idm/auth/oauth2/getattributes endpoint to validate an oauth2
    > access token and find out which user it belongs to).
    >
    > When I swap the certificate in my osp.jks keystore with a certificate
    > that has a dummy subject name and then restart all IdM components,
    > everything still works fine.


    That is an interesting test. I never thought to try that one. :)

    > So to my knowledge (please correct me if I'm wrong):
    > - the subject of the self-signed certificate in the osp.jks keystore is
    > irrelevant and doesn't have to match any particular DNS name.
    > - the self-signed certificate in the osp.jks keystore does not have to
    > be trusted by any IdM components (e.g. no need to import it into cacerts
    > files).


    The certificate of the Tomcat server is the one that matters the most I
    think. The cert has to match the DNS name.

    You are right that the OSP cert is for SAML if used. The Tomcat cert is
    the one that really matters.


  • >>> Therefore, if you are now going to be using a different means to
    >>> access (IP or different dns value), then you have regenerate the
    >>> certificate that OSP is using and change all of the mappings in the
    >>> SSO Client Tab.
    >>>

    >> Could you please explain why the subject of the certificate in the
    >> osp.jks matters? My understanding is that the key pair in the osp.jks
    >> keystore is only used by the OSP itself to:
    >> - digitally sign the oauth2 tokens it generates
    >> - verify the digital signature on oauth2 tokens in incoming requests
    >> (typically when an IdM component calls the OSP's
    >> /osp/a/idm/auth/oauth2/getattributes endpoint to validate an oauth2
    >> access token and find out which user it belongs to).
    >>
    >> When I swap the certificate in my osp.jks keystore with a certificate
    >> that has a dummy subject name and then restart all IdM components,
    >> everything still works fine.

    >
    > That is an interesting test. I never thought to try that one. :)
    >
    >> So to my knowledge (please correct me if I'm wrong):
    >> - the subject of the self-signed certificate in the osp.jks keystore
    >> is irrelevant and doesn't have to match any particular DNS name.
    >> - the self-signed certificate in the osp.jks keystore does not have to
    >> be trusted by any IdM components (e.g. no need to import it into
    >> cacerts files).

    >
    > The certificate of the Tomcat server is the one that matters the most I
    > think. The cert has to match the DNS name.
    >
    > You are right that the OSP cert is for SAML if used. The Tomcat cert is
    > the one that really matters.
    >

    The certificate in the osp.jks keystore indeed also serves as the OSP
    SAML SP signing
  • On 7/21/2017 4:46 AM, Anonymous wrote:
    >>>> Therefore, if you are now going to be using a different means to
    >>>> access (IP or different dns value), then you have regenerate the
    >>>> certificate that OSP is using and change all of the mappings in the
    >>>> SSO Client Tab.
    >>>>
    >>> Could you please explain why the subject of the certificate in the
    >>> osp.jks matters? My understanding is that the key pair in the osp.jks
    >>> keystore is only used by the OSP itself to:
    >>> - digitally sign the oauth2 tokens it generates
    >>> - verify the digital signature on oauth2 tokens in incoming requests
    >>> (typically when an IdM component calls the OSP's
    >>> /osp/a/idm/auth/oauth2/getattributes endpoint to validate an oauth2
    >>> access token and find out which user it belongs to).
    >>>
    >>> When I swap the certificate in my osp.jks keystore with a certificate
    >>> that has a dummy subject name and then restart all IdM components,
    >>> everything still works fine.

    >>
    >> That is an interesting test. I never thought to try that one. :)
    >>
    >>> So to my knowledge (please correct me if I'm wrong):
    >>> - the subject of the self-signed certificate in the osp.jks keystore
    >>> is irrelevant and doesn't have to match any particular DNS name.
    >>> - the self-signed certificate in the osp.jks keystore does not have
    >>> to be trusted by any IdM components (e.g. no need to import it into
    >>> cacerts files).

    >>
    >> The certificate of the Tomcat server is the one that matters the most
    >> I think. The cert has to match the DNS name.
    >>
    >> You are right that the OSP cert is for SAML if used. The Tomcat cert
    >> is the one that really matters.
    >>

    > The certificate in the osp.jks keystore indeed also serves as the OSP
    > SAML SP signing