Highlighted
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
527 views

IDM 4.8 - Identity Reporting OSP error during login

Jump to solution

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.

Labels (1)
1 Solution

Accepted Solutions
Highlighted
Knowledge Partner
Knowledge Partner

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

 

View solution in original post

7 Replies
Highlighted
Knowledge Partner
Knowledge Partner

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?

Highlighted
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

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 ism-configuration.properties | 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: ?redirect_uri=https%3A%2F%2Ffnaidm%2Efna%2Egov%2Eco%3A8443%2Fidmadmin%2Foauth%2Ehtml&client_id=idmadmin&response_type=code

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.

Highlighted
Knowledge Partner
Knowledge Partner

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.

0 Likes
Highlighted
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

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.

Highlighted
Knowledge Partner
Knowledge Partner

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

 

View solution in original post

Highlighted
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

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.

Highlighted
Knowledge Partner
Knowledge Partner

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

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.