Share all details about your problem, including any error messages you may have received.
Since upgrading IIQ 8.3p1 to 8.4p3 we have an issue when regular users try to use “manage password” on their own account(s).
End user experience: they click “manage password” and immediatly get a pop-up with a login box. This doesn’t make sense with our SSO setup. They cancel out of it, the error becomes “Unable to manage identity”. Closing that error brings them back to the home screen.
Technically we see a call to https://host/identityiq/ui/rest/identities/id ending in “401 unauthorized”.
In IIQ log: Uncaught JAX-RS exception. sailpoint.authorization.UnauthorizedAccessException: User does not have access to the resource
We have a Quicklink Population (/DynamicScope) “Own password manager” that has access to Quicklink “Manage Passwords” with the option “For Self”. This allowed us to let a group of regular users, without any other rights in IIQ, set their own account password for some systems.
Now this is getting blocked as they no longer seem to have the right to view their own identity attributes.
We could fix it by giving them the SPRight ViewIdentity, but then they could access information on all identities, that is not an option.
Is anyone aware of a way to let users use “manage passwords” only for their own accounts? Without exposing information of other identities?
@robbe_deneef Have you tried this in an environment without SSO? Do you see it working there?
I tried it in Sandbox with 8.5p1 and don’t see any issues. It is working fine for me.
Note: Help the community by marking successful fixes as solutions. Feel free to react(, , etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
@robbe_deneef Capability doesn’t support object filters. Have you tried this in any non-sso environment? Also please share your Own password manager Quicklink population for review?
Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(, , etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
All our environments use a SAML based identity provider, we have no pass through applications. So: no, unfortunatly that is not something I can test.
However in my understanding of the issue I don’t think that is the core of the problem. I just meant the login box doesn’t make sense from an end user perspective.
The login box is a side effect of the unauthorized error on the call to retrieve the identity details.
Sure I can share the Quicklink population, but there is not that much to see:
<DynamicScope created="1756301084789" id="<id>" modified="1756301084789" name="Own Password manager"> <Description>Quicklinks linked to the IT Role IT IIQ Own Password Manager</Description> <Selector> <IdentitySelector> <MatchExpression> <MatchTerm name="memberOf" type="Entitlement" value="CN=IIQ_QL_Own_Password_Manager,<domain info>"> <ApplicationRef> <Reference class="sailpoint.object.Application" id="<id>" name="AD INTERNAL"/> </ApplicationRef> </MatchTerm> </MatchExpression> </IdentitySelector> </Selector> </DynamicScope>
It just has the manage passwords quicklink checked with ‘for self’
@robbe_deneef Could you please try accessing IIQ using a direct server url https://<host ip address/name>:8080/identityiq/home.jsf and try resetting the password.
When we upgraded from 8.1 to 8.4 we also run into a similar issue, where if we were using the IIQ url , it was timing out and throwing the same login popup while when we try login using the individual server name, session remained persistent. On troubleshooting we found that there were some settings in GCP was not able to retain the session if traffic is going via LB.
Note: Found a fix? Help the community by marking the comment as solution. Feel free to react(, , etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
@robbe_deneef Could you please check what is the value of key: LoginAuthDurationMillis in your SystemConfiguration? If you have the version before your upgrade, please compare both SysConfig and see if you find any relevant differences.
We faced a similar issue, it looks like a sticky session issue. Since you are using the LB. to debug this issue, you can log in using individual servers and check if users are able to access links. If an individual server is able to access them, it would indicate a sticky session issue on the LB.
Hi @robbe_deneef Thank you, I might have missed it. This is an interesting issue. Then, the next step would be to do a deep dive into the logs. Can you share the logs from when you attempt to click the quick link? That would be the best place to debug this issue!
, 
, etc.) with an emoji to show your appreciation or message me directly if your problem requires a deeper dive.
