IDM 4.8 - Identity Reporting OSP error during login

Hello everybody.

I have a question related to IDM 4.8 installed under Red Hat 8.0.

In a new, fresh installation using 3 servers (one for eDirectory; another for UserApp OSP SSPR UserApp DB; the last one with IDMRPT idmdcs reporting database), I am receiving OSP errors only when I try to access IDMRPT web application.

All others are working fine (idmdash, idmadmin, idmdcs and so on).

I changed the log trace level of OSP from WARN to DEBUG and at the moment of the failure appeared the messaged on the attached file. This is the main mesaage that appears related to the IDMRPT application:

Preamble: [OIDP]
Priority Level: SEVERE
Java: internal.osp.oidp.service.oauth2.handler.RequestHandler.respondWithPageError() [606] thread=https-jsse-nio-8443-exec-12
Time: 2020-07-21T16:31:53.081-0500
Log Data: Code: internal.osp.oidp.service.oauth2.handler.HandlerException.<init>() [183]
Text: Profile Implicit not supported for client "rpt"

Did anybody faced something like this before? Any idea or suggestion would be greatly appreciated.

Regards, Andres.

  • I imagine it related to this line in the logs you posted.


    Preamble: [OIDP] Priority Level: FINER Java: internal.osp.oidp.service.oauth2.handler.Auth.getCommand() [164] thread=https-jsse-nio-8443-exec-12 Time: 2020-07-21T16:31:53.079-0500 Elapsed time: 118.36 microseconds Log Data: Parse OAuth 2.0 response_type: response_type: token Maps to: Implicit Grant profile


    It would be interesting to see what it says for other clients.

    From my system, a login attempt by a user generates:

    Preamble: [OIDP] Priority Level: FINER Java: internal.osp.oidp.service.oauth2.handler.Grant.getCommand() [198] thread=https-jsse-nio-8443-exec-13 Time: 2020-07-21T18:39:54.637-0400 Elapsed time: 10.689 microseconds Log Data: Parse OAuth 2.0 response_type or grant_type: response_type: code Maps to: Authorization Code Grant profile


    Which I think is give a code, then it asks for a token, which looks like this:


    Preamble: [OIDP] Priority Level: FINER Java: internal.osp.oidp.service.oauth2.handler.Grant.getCommand() [198] thread=https-jsse-nio-8443-exec-3 Time: 2020-07-21T18:40:05.644-0400 Elapsed time: 7.13 microseconds Log Data: Parse OAuth 2.0 response_type or grant_type: grant_type: authorization_code Maps to: Access Token Request profile


    But I also have this one:

    Preamble: [OIDP] Priority Level: FINER Java: internal.osp.oidp.service.oauth2.handler.Grant.getCommand() [198] thread=https-jsse-nio-8443-exec-12 Time: 2020-07-21T18:40:09.187-0400 Elapsed time: 9.415 microseconds Log Data: Parse OAuth 2.0 response_type or grant_type: grant_type: client_credentials Maps to: Client Credentials Grant profile


    I forget what client uses client credentails, you can look in ism-config.

    And you also get refreshes as:


    Preamble: [OIDP] Priority Level: FINER Java: internal.osp.oidp.service.oauth2.handler.Token.getCommand() [180] thread=https-jsse-nio-8443-exec-14 Time: 2020-07-21T18:40:35.354-0400 Elapsed time: 59.594 microseconds Log Data: Parse OAuth 2.0 response_type or grant_type: grant_type: refresh_token Maps to: Refresh Access Token profile


    So I have in my ism-config, pulling them all together in one place:

    com.netiq.dcsdrv.response-types = password com.netiq.sspr.response-types = code,token com.microfocus.workflow.response-types = client_credentials com.netiq.forms.response-types = code,token com.netiq.idmadmin.response-types = code com.netiq.rpt.rpt-web.response-types = code com.netiq.rbpmrest.response-types = password com.netiq.idmengine.response-types = password com.netiq.rbpm.response-types = code,client_credentials com.netiq.idmdash.response-types = code,token com.netiq.rpt.response-types = password com.netiq.idmdcs.response-types = code,token

    So since this reporting, what values do you have for the rpt response-type... 

    Actually, I did not configure reporting on this one, did they not move to idmrpt as the new client?

    What values do you have in comparison?

  • Hello Geoff. Thank your for your answer.

    Reviewing all ism-config parameters related to the response-types, those are exactly as you put in your message:

    [root@IDMSERVER3 conf]# cat | grep response-types
    com.microfocus.workflow.response-types = client_credentials
    com.netiq.forms.response-types = code,token
    com.netiq.idmdash.response-types = code,token
    com.netiq.idmadmin.response-types = code
    com.netiq.idmdcs.response-types = code,token
    com.netiq.idmengine.response-types = password
    com.netiq.rbpm.response-types = code,client_credentials
    com.netiq.rbpmrest.response-types = password
    com.netiq.sspr.response-types = code,token
    com.netiq.rpt.response-types = password
    com.netiq.rpt.rpt-web.response-types = code

    One thing to take into account (maybe that's a mistake) is that these parameters are configured in the UserApp OSP server. The IDMRPT web application is installed in another server, and the ism-config on that server does not have all those parameters because I am authenticating with the same OSP as UserApp. Should I configure those parameters as well in the ism-config for the IDMRPT's Tomcat conf?

    Just like on your system, I also receive successful messages for the other web applications, and the messages returned by OSP's log are basically the same as you put before:

    Preamble: [OSP]
    Priority Level: FINER
    Java: internal.osp.common.logging.HttpRequestLogger.log() [340] thread=https-jsse-nio-8443-exec-2
    Time: 2020-07-22T14:40:26.915-0500
    Log Data: HttpServletRequest (Number 76)
    Method: GET
    Request URL: /osp/a/idm/auth/oauth2/grant
    Query String: ?

    Preamble: [OIDP]
    Priority Level: FINER
    Java: internal.osp.oidp.service.oauth2.handler.Grant.getCommand() [198] thread=https-jsse-nio-8443-exec-2
    Time: 2020-07-22T14:40:26.916-0500
    Elapsed time: 14.744 microseconds
    Log Data: Parse OAuth 2.0 response_type or grant_type:
    response_type: code
    Maps to: Authorization Code Grant profile

    Preamble: [OIDP]
    Priority Level: FINER
    Java: internal.osp.oidp.service.profile.authentication.ContractExecutionProfile.init() [345] thread=https-jsse-nio-8443-exec-2
    Time: 2020-07-22T14:40:26.923-0500
    Elapsed time: 83.468 microseconds
    Log Data: Initialize contract execution profile.

    Looking forward to your comments. Thanks in advance.

    Regards, Andres.

  • So is the client secret configs for rpt on the OSP server, the same as set on the Reporting server?

    Normally you set the secret in two places.

    1) the OSP side defining what incoming connections will use from OSP's view.

    2) The Application side, defining what they will send to OSP.

    All on one server, this one setting, sets for both app and OSP.  So should be set teh same on both boxes, but Ii am not yet certain that is your issue.

  • Hello again Geoff.

    I configured the parameters on each idm-config file (the one located on the OSP Server, and the other where we have IDMRPT installed). The idmdcs web application open OK (like before), but the IDMRPT web application is still reporting the same issue.

    I checked today on every IDMRPT Tomcat log, and through catalina.out I receive this message:

    23-Jul-2020 17:34:58.849 INFO [https-jsse-nio-8443-exec-7] org.apache.tomcat.util.http.parser.Cookie.logInvalidHeader A cookie header was received [eyJhbGciOiJSUzI1NiIsImtpZCI6IkY4X21lX0NTd1UxV05IbUx5QU9ZX1RDMERndyJ9.eyJpc3MiOiJodHRwczovL2ZuYWlkbS5mbmEuZ292LmNvOjg0NDMvb3NwL2EvaWRtL2F1dGgvb2F1dGgyIiwiZXhwIjoxNTk1NTQzODE4LCJuYmYiOjE1OTU1NDM2OTgsImlhdCI6MTU5NTU0MzY5OCwiYXVkIjpbImlkbWRjcyIsImlkbWVuZ2luZSIsInNzcHIiLCJ3b3JrZmxvdyIsInJwdHciLCJpZG1kYXNoIiwicnB0IiwicmJwbSIsImRjc2RydiIsInJicG1yZXN0IiwiaWRtYWRtaW4iLCJmb3JtcyJdLCJzdWIiOiJiaXNhZHVzLWFlODZmYTUyMTM3OTVjNGJhMDhhYWU4NmZhNTIxMzc5IiwidHhuIjoib1lReEVNMDBFZXFUV1FCUVZxSjBMZyIsInNjb3BlIjpbImlzbSJdLCJhdXRoX3RpbWUiOiIxNTk1NTQzNjU5IiwiZmlyc3RfbmFtZSI6IlVzZXJBcHBsaWNhdGlvbiIsImxhc3RfbmFtZSI6IkFkbWluaXN0cmF0b3IiLCJuYW1lIjoiY249dWFhZG1pbixvdT1TUlYsbz1GTkEiLCJhdXRoX3NyY19pZCI6ImJpc2FkdXMiLCJleGNsdWRlZCI6WyJyb2xlcyJdLCJfcHZ0IjoiQUVNQVN3SjFBQzVCQUJjQUlBQUFBQUFBQUdOdVBYVmhZV1J0YVc0c2IzVTlVMUpXTEc4OVJrNUJZV1U0Tm1aaE5USXhNemM1TldNMFltRXdPR0ZoWlRnMlptRTFNakV6TnpsX0FLd0E3USJ9.MKJNa2yN7PyZWXpKWIaDyJBYAqEdlC9AZXs4oU0AO8joDt951dNXQYfeSwCPFlC9WSyznuA5mFQmGI3ULX129pcd5cONO2StCDVb74htpXqiHPHALCprbH3SV8WkL8RMXvj7FCkQVzN3C4AqcVRAlmLtLz1-usj7Wc7-bFZHFhg5obWClklaIeUnVe1z2Hi1vnXJdLSzoGZ2msd-HPZTGfUPRcWk7tc8pM4Vvbbh-MhhI1Eknb6rahhSVe9z1PqK11cx-iCWyXsW8-DVXdLZxs-sBmwUI3fYtNtf1YZ2Mk_ttTr72Te43yyNKCUFv8-ICQ81hDP8LlIgYz96vXV8zQ] that contained an invalid cookie. That cookie will be ignored.
    Note: further occurrences of this error will be logged at DEBUG level.

    So that might be another situation. Might be related to keystore certificates? Anyway is really odd because, as I said before, the idmdcs web app opens just fine.

    Looking forward to any other comment or suggestion. Thanks once again.

    Regards, Andres.

  • Verified Answer

    So keystores are a fun question... Do you have the Signer of each cert in the various keystores? ?

    So OSP private key is usually self signed, so you need to export its public key.

    The Tomcat instance on both sides is often publically signed, in which case you want the CA's (and intermediate) that signed the cert.  Usually NOT the public key of the server cert itself, since that will in theory change every 1-2 years, but CA's are mostly forever (or 2030 or so anyway).


  • Hello Geoff.

    The issue han been solved, after a careful reviewing of all keystores involved (UserApp's Tomcat, OSP, IDMRPT's Tomcat, cacerts) there was a couple of certificates missing in the cacerts.

    After importing those, and reviewing the ism-conf parameters based on your input, the issue has been solved.

    Thank you very much for your suggestions!

    Regards, Andres.

  • Keystores and URL's are the hardest part of OSP to get right.

    The irony is that it is pretty simple. But the error messages are kind of less than helpful.  As I called out, I actually found a specific error message thatw ould help but is specifically left vague which annoys me. (In theory security issue).