Custom SSO Provider for Identity Mgr 4.5 UA


Hi all,

As we know, Identity Mgr 4.5 UA uses OSP, and OSP supports UserID /
Password, Kerberos and SAML... but seems to not support a custom SSO
header as it was possible with Identity Mgr 4.0.x, correct?

4.5:
Understanding Authentication with One SSO Provider
http://tinyurl.com/oplekly

4.0.x
Custom SSO Provider
https://www.netiq.com/documentation/idm402/agpro/data/b6iiw3v.html

Are you aware of any workarounds / settings/ possibilities to make
Identity Mgr 4.5 UA work with a custom SSO header (as specified with
4.0.x)?

Thx,
Norman


--
nleuenbergerctp
------------------------------------------------------------------------
nleuenbergerctp's Profile: https://forums.netiq.com/member.php?userid=9914
View this thread: https://forums.netiq.com/showthread.php?t=53761

  • On 6/25/2015 4:56 AM, nleuenbergerctp wrote:
    >
    > Hi all,
    >
    > As we know, Identity Mgr 4.5 UA uses OSP, and OSP supports UserID /
    > Password, Kerberos and SAML... but seems to not support a custom SSO
    > header as it was possible with Identity Mgr 4.0.x, correct?
    >
    > 4.5:
    > Understanding Authentication with One SSO Provider
    > http://tinyurl.com/oplekly
    >
    > 4.0.x
    > Custom SSO Provider
    > https://www.netiq.com/documentation/idm402/agpro/data/b6iiw3v.html
    >
    > Are you aware of any workarounds / settings/ possibilities to make
    > Identity Mgr 4.5 UA work with a custom SSO header (as specified with
    > 4.0.x)?


    The code for that was removed, and replaced with OSP as far as I can tell.

    (Honestly, OSP is a better solution than the 4.02 one).

    I have gotten it to work with Shibboleth and NAM over SAML. There was a
    minor bug that was easy to work around that is now fixed in OSP 4.5 HP1.

    What is providing your header auth at this time?


  • all this has been implemented as shown in the doc „Implementing and
    Deploying a Custom SSO Provider“...

    SSO Header: BASE64<SSO UserID>:<TimeStamp>:BASE64(<Signature>)

    ....on the front end / sending party we do have an airlock reverse proxy
    (https://www.airlock.com/en/products/airlock-waf/), and I've been told
    that we need to stay with the custom SSO header… no SAML a.o. available…


    ....do you think there is a way to the the “custom SSO header”
    feature/code back into the product?


    --
    nleuenbergerctp
    ------------------------------------------------------------------------
    nleuenbergerctp's Profile: https://forums.netiq.com/member.php?userid=9914
    View this thread: https://forums.netiq.com/showthread.php?t=53761

  • On 2015-06-25 17:14, nleuenbergerctp wrote:
    >
    > all this has been implemented as shown in the doc �Implementing and
    > Deploying a Custom SSO Provider�...
    >
    > SSO Header: BASE64<SSO UserID>:<TimeStamp>:BASE64(<Signature>)
    >
    > ...on the front end / sending party we do have an airlock reverse proxy
    > (https://www.airlock.com/en/products/airlock-waf/), and I've been told
    > that we need to stay with the custom SSO header� no SAML a.o. available�
    >
    >
    > ...do you think there is a way to the the �custom SSO header�
    > feature/code back into the product?
    >
    >

    You can still use airlock as a proxy even if you do SAML, I've environments combining both SAML and proxy.

    If airlock can't do federation I think that you will have better luck setting up another federation product and use that
    together with the airlock proxy than waiting for the custom SSO functionality to be added to OneSSO Provider. The custom SSO
    functionality was great in the days but today there are well known standards for achieving the same goal (SSO).

    Best regards,
    Tobias

  • On the same problem (making OSP work with a Custom IDP -
    SimpleSAMLPHP)....

    I have been successful in making SimpleSAMLPHP to accept the header
    attribute from the FrontEnd authentication system (say Airlock) and
    generate a SAML Response to successfully Authenticate against OSP.
    This all works well when the flow is SP-Initiated as below:

    Access /IDMProv which is protected by OSP ---> OSP redirects to IDP with
    SAMLAuthnRequest --> IDP generates SAML Response --> OSP validates the
    SAML Response

    When I test the same setup with IDP-initiated, OSP is always going for
    extra loop of SAMLAuthnRequest-->SAMLResponse... This is what is going
    on...

    Access IDP --> Generate and POST SAML Response and RelayState URL
    (/IDMProv) to OSP --> OSP cosumes, validates, verifies the SAML Response
    --> Prints nLogin Success message for the user --> then fails to
    successfully redirect to the /IDMProv service ....instead at the last
    step, OSP generates a SAMLAuthnRequest and redirects back to IDP for a
    SAML Response...then OSP successfully logs in the user to /IDMProv.

    _Log_messages_(in_the_OSP_log)_after_first_SAML_Response_

    -[OIDP]
    Time: 2015-07-29T13:56:39.627 0200
    Level: INFO
    Java Execution:
    Class: com.novell.oidp.session.NIDPSession
    Method: authenticate
    Line Number: -1
    Thread: localhost-startStop-1
    Message: Authenticated user cn=testuser,dc=acme in User Store
    Authentication from IDM eDir with roles

    [OIDP]
    Time: 2015-07-29T14:31:15.113 0200
    Level: INFO
    Java Execution:
    Class: com.novell.oidp.saml2.profile.SAML2SSOProfile
    Method: successfulAuthentication
    Line Number: -1
    Thread: http-bio-8443-exec-3
    Message: nLogin succeeded, redirecting to https://idmtest:8443/IDMProv.

    [OIDP]
    Time: 2015-07-29T14:31:15.226 0200
    Level: WARN
    Java Execution:
    Class: com.novell.oidp.source.ldap.jndi.JNDIAuditEventListener
    Method: accept
    Line Number: -1
    Thread: OSP JNDI Connection Retirement
    Event:
    Id: 0.0.6.1
    Desc: Close connection 41e41871-0a67-40fc-a6af-ab0a55c9d6c9 to user
    store replica
    Outcome: 0
    Message: TerminateConnection

    [OIDP]
    Time: 2015-07-29T14:31:15.912 0200
    Level: INFO
    Java Execution:
    Class: com.novell.oidp.profile.LoginProfile
    Method: login
    Line Number: -1
    Thread: http-bio-8443-exec-9
    MESSAGE: PROCESSING LOGIN REQUEST WITH TARGET:
    http://tinyurl.com/og6fef7, SAVED TARGET: HTTPS
    ://IDMTEST:8443/OSP/A/IDM/AUTH/OAUTH2/IMPLICITCONTINUE?PRIVATEID=4F106EBA392567D357BC

  • While I had some fun digging at the SAML messages and in to OSP, it
    seems to me, OSP supports only SP-initiated and not IDP-initiated SAML
    SSO..

    here's why.

    IDP-Initiated Flow:

    Step 1) User Access SimpleSAMLPHP IDP : It authenticates the user,
    generates the SAML Response and then POSTs the html form containing
    these parameters to Assertion Consumer Service(ACS) URL of OSP
    https://idmtest:8443/osp/a/idm/auth/saml2/spassertion_consumer
    a) SAML Response
    b) RelayState URL that user wants to see at IDM after
    successful validation of SAML Response is complete.

    Step 2) ACS at OSP consumes the SAML Response, verifies the signature,
    authenticates the user (see log messages posted last time, a day ago)
    and then tries to redirect to the end target URL (which is RelayState
    URL sent by IDP), via the OAuth Service. But OAuth endpoint is expecting
    the parameters as "privateId", "irdpkg" and "client_id" (we will see why
    in Step 3). Since it doesn't get the OAuth URL as it expects, it
    initiates a new request to the IDP with SAMLAuthnRequest as shown
    below.

    -<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

    Consent="urn:oasis:names:tc:SAML:2.0:consent:unavailable"
    ForceAuthn="false"
    ID="idnWmuRuiKGFQJqZt61NsdZNUZaWQ"
    IsPassive="false"
    IssueInstant="2015-07-30T11:05:52Z"

    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
    Version="2.0"

    target="">idmtest:8443/.../authcodecontinue
    >


    <saml:Issuer>idmtest:8443/.../saml:Issuer>
    <samlp:NameIDPolicy
    Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    </samlp:AuthnRequest>-

    If you look at it, "target" parameter is a OAuth endpoint URL and not
    the actual RelayState URL like in a standard SAML implementation... I
    see this as detour of ideal SAML flow...

    Step 3) Then IDP treats the SAMLAuthnRequest as a fresh session (OSP is
    starting a new HTTP session), regenerates the SAML Response but POSTs
    this time different parameter along with SAML Response...

    a) SAMLResponse: PHNhb##removed as it is very large value###==
    b) RelayState: MA==


    This time OSP knows that this was a request it received earlier by
    referring to parameters sent earlier in the "target" (privateId, irdpkg
    and client_id) and then successfully redirect the user to the actual
    RelayState URL in step 1.

    Going with this... we cannot achieve the IDP-initiated SAML SSO with OSP
    but only the SP-initiated. IMO, this is not a elegant implementation of
    SAML though it is a leaps forward from older header based SSO.

    Welcome your thoughts, as we still need a way to achieve IDP-initiated
    SSO with very first POST of SAML Response.


    --
    srinathu
    ------------------------------------------------------------------------
    srinathu's Profile: https://forums.netiq.com/member.php?userid=10138
    View this thread: https://forums.netiq.com/showthread.php?t=53761


  • I have got this piece working for our setup with IDP handling the
    SAMLAuthRequest using existing session of the user and generate another
    SAML response in Step 3) described from previous reply....

    While I'm happy with this tweaked IDP as it is working, but still not a
    happy customer with OSP not supporting IDP-initiated SAML logon.

    At least, let's hope to see a better documentation on the SAML support
    in OSP, which greatly avoids useless digging in to OSP's logic flow to
    find out the real problem...


    --
    srinathu
    ------------------------------------------------------------------------
    srinathu's Profile: https://forums.netiq.com/member.php?userid=10138
    View this thread: https://forums.netiq.com/showthread.php?t=53761