Micro Focus Contributor
Micro Focus Contributor
516 views

IDGov3.5 and IDRpt on own servers authentication issue

Hi All,

I've installed identity governance and reporting on their own respective servers. Both are currently installed with HTTP and are just standard at the moment to avoid introducing any certificate issues with OSP.

Server A = IdGov3.5.0
Server B = ID Reporting
Server C = postgreSQL

Both servers have their own OSP installed and I am getting authentication issues when trying to log into identity reporting.

Mainly this error on the reporting main page
USERNAME does not have access to the reporting application. Logout and re-login as another user or go to the home page for other options.



In the log on Server B I get the following log message
[WARNING] 2019-05-09 10:52:34 com.novell.idm.rpt.core.server.j2ee.AuthFilter checkPermissionOAuth - [RPT-CORE] User ##### (cn=#####,ou=users,o=#####) is authenticated and logged in, but does not have access to the reporting application.



and on Server A I get the error message
[WARNING] 2019-05-09 10:52:34 com.netiq.iac.server.common.auth.OAuthManager validateToken - [IG-SERVER] Token validation failed. HTTP status code: 0 Detail message from authentication server: JWS signature is invalid



I can provide the ism-configuration.properties file if required. I am able to LDAP authenticate into governance just fine and use the application as intended, however I am unable to log into reporting. I have set the user that I am trying to log into reporting with as both a global administrator and report administrator in Identity governance on ServerA.


Having never set up reporting before I am unsure as to why I keep getting a [IG-SERVER] Token validation failed.

If anyone can point me in the right direction that would be great. I'm sure it's probably something to do with how I've set identity governance URL's in the reporting (server B) for some of the Re-direct AUTH URL's. but these were set during setup when it specifically asked for identity governance details and not reporting.

Any guidance on how to set up reporting solely with identity governance would be appreciated as the documentation isn't super clear on this type of setup.


Thanks

Lewis
0 Likes
12 Replies
Knowledge Partner
Knowledge Partner

Re: IDGov3.5 and IDRpt on own servers authentication issue

On 5/8/2019 9:26 PM, lejohnston wrote:
>
> Hi All,
>
> I've installed identity governance and reporting on their own respective
> servers. Both are currently installed with HTTP and are just standard at
> the moment to avoid introducing any certificate issues with OSP.
>
> Server A = IdGov3.5.0
> Server B = ID Reporting
> Server C = postgreSQL
>
> Both servers have their own OSP installed and I am getting
> authentication issues when trying to log into identity reporting.
>
> Mainly this error on the reporting main page
>
> Code:
> --------------------
> USERNAME does not have access to the reporting application. Logout and re-login as another user or go to the home page for other options.
> --------------------
>
>
>
> In the log on Server B I get the following log message
>
> Code:
> --------------------
> [WARNING] 2019-05-09 10:52:34 com.novell.idm.rpt.core.server.j2ee.AuthFilter checkPermissionOAuth - [RPT-CORE] User ##### (cn=#####,ou=users,o=#####) is authenticated and logged in, but does not have access to the reporting application.
> --------------------
>
>
>
> and on Server A I get the error message
>
> Code:
> --------------------
> [WARNING] 2019-05-09 10:52:34 com.netiq.iac.server.common.auth.OAuthManager validateToken - [IG-SERVER] Token validation failed. HTTP status code: 0 Detail message from authentication server: JWS signature is invalid
>
> --------------------
>
>
>
> I can provide the ism-configuration.properties file if required. I am
> able to LDAP authenticate into governance just fine and use the
> application as intended, however I am unable to log into reporting. I
> have set the user that I am trying to log into reporting with as both a
> global administrator and report administrator in Identity governance on
> ServerA.
>
>
> Having never set up reporting before I am unsure as to why I keep
> getting a [IG-SERVER] Token validation failed.
>
> If anyone can point me in the right direction that would be great. I'm
> sure it's probably something to do with how I've set identity governance
> URL's in the reporting (server B) for some of the Re-direct AUTH URL's.
> but these were set during setup when it specifically asked for identity
> governance details and not reporting.
>
> Any guidance on how to set up reporting solely with identity governance
> would be appreciated as the documentation isn't super clear on this type
> of setup.


So where is OSP running? You say both servers. I suspect that you might
be better off with just one OSP.

Also, in the IDG Config, Admin users (the first item I think) did you
flag your user as a Reporting user? That I think is the first error of
logged in but not allowed.



0 Likes
Highlighted
Micro Focus Contributor
Micro Focus Contributor

Re: IDGov3.5 and IDRpt on own servers authentication issue

Thanks Geoff, i'm going to wipe the server and re-install reporting without OSP and use the Identity governance OSP instance during the setup instead so there is only one OSP.

When you say admin users, where do you mean? in configupdate? or in the actual identity governance web interface; I have set the user i'm logging in to reporting with as both a global administrator and a report administrator. Is there another option elsewhere? e.g. during the install "Admin users container DN"
0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: IDGov3.5 and IDRpt on own servers authentication issue

Hi Geoff,

I've re-installed identity reporting as a stand alone application and connected it with the identity governance OSP service(ServerA). that is all working and SingleSign on works between the two applications flawlessly. However, i still get the error message from earlier
USERNAME does not have access to the reporting application. Logout and re-login as another user or go to the home page for other options.
when browsing to the identity reporting application using the top right hand corner icon within identity governance.

I'm confident this is no longer an OSP issue, rather an application issue.

Any help would be appreciated.

Thanks in advance,

Lewis
0 Likes
Knowledge Partner
Knowledge Partner

Re: IDGov3.5 and IDRpt on own servers authentication issue

On 5/10/2019 1:14 AM, lejohnston wrote:
>
> Hi Geoff,
>
> I've re-installed identity reporting as a stand alone application and
> connected it with the identity governance OSP service(ServerA). that is
> all working and SingleSign on works between the two applications
> flawlessly. However, i still get the error message from earlier
>> USERNAME does not have access to the reporting application. Logout and
>> re-login as another user or go to the home page for other options. when browsing to the identity reporting application using the top right

> hand corner icon within identity governance.
>
> I'm confident this is no longer an OSP issue, rather an application
> issue.


In IDG, Administration/configuration item, there is an Admin
User/permissions section. Here you define which users have access to
IDG. That is what this error is about. Need to add the user in IDG to
allow access. Internal access control based on permissions inside the app.

0 Likes
Knowledge Partner
Knowledge Partner

Re: IDGov3.5 and IDRpt on own servers authentication issue

On 5/9/2019 9:14 PM, lejohnston wrote:
>
> Thanks Geoff, i'm going to wipe the server and re-install reporting
> without OSP and use the Identity governance OSP instance during the
> setup instead so there is only one OSP.
>
> When you say admin users, where do you mean? in configupdate? or in the
> actual identity governance web interface; I have set the user i'm
> logging in to reporting with as both a global administrator and a report



> administrator. Is there another option elsewhere? e.g. during the
> install "Admin users container DN"


This is the one I was refering to.

0 Likes
Micro Focus Expert
Micro Focus Expert

Re: IDGov3.5 and IDRpt on own servers authentication issue

On 5/10/19 7:00 AM, Geoffrey Carman wrote:
> On 5/9/2019 9:14 PM, lejohnston wrote:
>>
>> Thanks Geoff, i'm going to wipe the server and re-install reporting
>> without OSP and use the Identity governance OSP instance during the
>> setup instead so there is only one OSP.
>>
>> When you say admin users, where do you mean? in configupdate? or in the
>> actual identity governance web interface; I have set the user i'm
>> logging in to reporting with as both a global administrator and a report

>
>
>> administrator. Is there another option elsewhere? e.g. during the
>> install "Admin users container DN"

>
> This is the one I was refering to.
>

Greetings,
In order to access ID Reporting as part of ID Gov:

1) They have to be utilizing the same OSP server(s). Be that a single
instance of OSP or a cluster of OSP servers.

2) During the install of ID Reporting you must provide the URL for ID
Gov single server or the Load Balancer URL that will get one to the
cluster of the ID Gov servers.

3) Within ID Gov, under Configuration -> Authorization Assignments you
must set a User (which is from the same Authorization source that OSP is
pointing to) to being either a Global Administrator or a Report
Administrator.
Note: If you collect Groups then it can be a group here as well and then
the auth check will see that they are in Group within the correct Admin
assignment


4) Since Reporting will call to ID Gov to check the Authorization (after
the Authentication has been done) ID Gov must be running. Also, if you
are utilizing HTTPS then the certificate from the ID Gov's tomcat must
be in the application.keystore file of the remote ID Reporting server.

--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Knowledge Partner
Knowledge Partner

Re: IDGov3.5 and IDRpt on own servers authentication issue

> 4) Since Reporting will call to ID Gov to check the Authorization (after
> the Authentication has been done) ID Gov must be running.  Also, if you
> are utilizing HTTPS then the certificate from the ID Gov's tomcat must
> be in the application.keystore file of the remote ID Reporting server.



/opt/netiq/idm/apps/tomcat/conf/apps-truststore.pkcs12 right?

0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: IDGov3.5 and IDRpt on own servers authentication issue

Hi Steve / Geoff,

- IDGov and ID Reporting are using the same OSP server.
- In configupdate the admin users DN value is set to the users container of my directory.
- Under Authorization Assignments I have set the admin user (located in the users OU) to be a report administrator and a global administrator. I have also set another general user as a report administrator with no luck and tried logging in with no luck.

- I specified the URL of the IDGov server during installation of ID Reporting. To confirm though, what value is this in ism-configuration and I can double check?

- I am running both applications without SSL at the moment and OSP is also running on HTTP.

- Is there any requirement for anything other than identity to be collected on the identity governance server?

One thing I did notice in ism-configuration.properties was this line :

com.netiq.rpt.role.config = {\"auth-sources\":[{\"auth-source-id\":\"bisadus\",\"combine-generators\":false,\"role-generators\":[{\"type\":\"accessreview\",\"role-map-casesensitive\":true,\"role-map\":[{\"mapped-role\":\"ADM\",\"rpt-role\":\"reportadmin\"},{\"mapped-role\":\"RPTA\",\"rpt-role\":\"reportadmin\"}]}]}]}



This doesn't look correct as auth-source-id is a value I don't recognise. but perhaps it's an internal IDGov value?

Thanks in advance,

Lewis
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: IDGov3.5 and IDRpt on own servers authentication issue

On 5/12/19 8:14 PM, lejohnston wrote:
>
> Hi Steve / Geoff,
>
> - IDGov and ID Reporting are using the same OSP server.
> - In configupdate the admin users DN value is set to the users container
> of my directory.
> - Under Authorization Assignments I have set the admin user (located in
> the users OU) to be a report administrator and a global administrator. I
> have also set another general user as a report administrator with no
> luck and tried logging in with no luck.
>
> - I specified the URL of the IDGov server during installation of ID
> Reporting. To confirm though, what value is this in ism-configuration
> and I can double check?
>
> - I am running both applications without SSL at the moment and OSP is
> also running on HTTP.
>
> - Is there any requirement for anything other than identity to be
> collected on the identity governance server?
>
> One thing I did notice in ism-configuration.properties was this line :
>
>
> Code:
> --------------------
> com.netiq.rpt.role.config = {\"auth-sources\":[{\"auth-source-id\":\"bisadus\",\"combine-generators\":false,\"role-generators\":[{\"type\":\"accessreview\",\"role-map-casesensitive\":true,\"role-map\":[{\"mapped-role\":\"ADM\",\"rpt-role\":\"reportadmin\"},{\"mapped-role\":\"RPTA\",\"rpt-role\":\"reportadmin\"}]}]}]}
>
> --------------------
>
>
>
> This doesn't look correct as auth-source-id is a value I don't
> recognise. but perhaps it's an internal IDGov value?
>
> Thanks in advance,
>
> Lewis
>
>

Greetings,
The entry in the ism-configuration.properties file is correct. You
need to look at the REST call that is made when you go to ID Reporting.
It might be easier to open a Service Request with Support and provide a
HAR file so they can forward that to me.



--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: IDGov3.5 and IDRpt on own servers authentication issue

Thanks Steve,

I managed to find the issue. it seems the config file under /opt/netiq/idm/apps/idrpt/conf/rpt-configuration-init.properties had some corrupt values in it. They had somehow managed to add URL encoded values for authserver URL and OSP server URL. e.g. http%3A%2F%2F

Not sure how this happened, perhaps something during the install or fat fingers from myself. who knows.


Corrected these values to the proper URL's... restarted the tomcat service... and it still did not work.


cleared out the temp and work directories under the tomcat directory. restarted the service again and viola! logged into identity reporting and was able to see the home page.



Thanks for both yours and Geoff's help.
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: IDGov3.5 and IDRpt on own servers authentication issue

On 5/12/19 10:16 PM, lejohnston wrote:
>
> Thanks Steve,
>
> I managed to find the issue. it seems the config file under
> /opt/netiq/idm/apps/idrpt/conf/rpt-configuration-init.properties had
> some corrupt values in it. They had somehow managed to add URL encoded
> values for authserver URL and OSP server URL. e.g. http%3A%2F%2F
>
> Not sure how this happened, perhaps something during the install or fat
> fingers from myself. who knows.
>
>
> Corrected these values to the proper URL's... restarted the tomcat
> service... and it still did not work.
>
>
> cleared out the temp and work directories under the tomcat directory.
> restarted the service again and viola! logged into identity reporting
> and was able to see the home page.
>
>
>
> Thanks for both yours and Geoff's help.
>
>

Greetings,
As a follow-up I had an email exchange with lejohnston. Updating
the rpt-configuration-init.properties would not have improved the
situation as that is generated at install time and then added/merged to
the actual ism-configuration.properties. lejohnston outlined that some
changes were made in configupdate as well.

It would have been the changes in configupdate and clearing out Tomcat's
caching directory that resolved the issue.



--
Sincerely,
Steven Williams
Principal Enterprise Architect
Micro Focus
0 Likes
Knowledge Partner
Knowledge Partner

Re: IDGov3.5 and IDRpt on own servers authentication issue

>
> One thing I did notice in ism-configuration.properties was this line :
>
>
> Code:
> --------------------
> com.netiq.rpt.role.config = {\"auth-sources\":[{\"auth-source-id\":\"bisadus\",\"combine-generators\":false,\"role-generators\":[{\"type\":\"accessreview\",\"role-map-casesensitive\":true,\"role-map\":[{\"mapped-role\":\"ADM\",\"rpt-role\":\"reportadmin\"},{\"mapped-role\":\"RPTA\",\"rpt-role\":\"reportadmin\"}]}]}]}
>
> --------------------
>
>
>
> This doesn't look correct as auth-source-id is a value I don't
> recognise. but perhaps it's an internal IDGov value?


If you ever set OSP logging to ALL (in tomcat/bin/setenv.sh) and read
through the acres of logs you get you will see that OSP is actually a
much more full featured NAM competitor than we 'see'. There is actually
a version used in xAccess (Social Access, etc) that has an actual GUI.

OSP ships with a default ID source named bisadus, and then you specify
the parameters in the config. But the name of the ID Source is hard
coded. You will see the tenant name is hard coded as well.

I do recommend reading through an entire OSP log, it gives some insight
into what is happening under the covers, even though it is long and boring.

You can see that variables, defined in ism-configuration.properties are
used throughout to configure OSP. It is quite a clever approach actually.
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.