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.
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).
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.
-[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..
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.
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.