Idm REST APIs return 401 unauthorized

Troubleshooting
, , , , ,
#1

I am getting 401 error while testing out the IDM REST endpoints as below:

curl --location ‘/openidm/managed/user?_prettyPrint=true&_queryId=query-all-ids&_totalPagedResultsPolicy=NONE#1.0_query_id_query-all-ids’ --header ‘Accept-API-Version: resource=1.0’ --header ‘Accept: application/json’ --header ‘X-OpenIDM-Username: openidm-admin’ --header ‘X-OpenIDM-Password: openidm-admin’ --header ‘Authorization: Basic AUTH_TOKEN’ -v

  • Trying ipaddres:80…
  • Connected to idm.forgerock (172.16.2.147) port 80 (#0)

GET /openidm/managed/user?_prettyPrint=true&_queryId=query-all-ids&_totalPagedResultsPolicy=NONE HTTP/1.1
Host: idm.forgerock
User-Agent: curl/7.74.0
Accept-API-Version: resource=1.0
Accept: application/json
X-OpenIDM-Username: openidm-admin
X-OpenIDM-Password: openidm-admin
Authorization: Basic AUTH_TOKEN

  • Mark bundle as not supporting multiuse
    < HTTP/1.1 401 Unauthorized
    < date: Thu, 21 Sep 2023 01:36:52 GMT
    < www-authenticate: Bearer realm=“IDM”
    < content-length: 0
    < x-envoy-upstream-service-time: 3
    < server: envoy
    <
  • Connection #0 to host idm.forgerock left intact

It fails even with different user credentials with the appropriate roles: openidm-admin & openidm-authorized. My test instance is running in GKE cluster(1.27.3-gke.100) with Forgeops CDK 7.3 installation. Perhaps, I would like to know an alternative way to authenticate the REST calls for IDM. If anybody knows, please confirm that the openidm admin credential is not the only way to authenticate for accessing the IDM REST endpoints.

I am a bit lost about how to troubleshoot this issue since there is no logs found in the IDM service.

Any advice would be greatly appreciated!!!

#2

Hi @jiyun_kang - two things stand out to me here.

  1. I see you are providing the X-OpenIDM-Username and X-OpenIDM-Password headers, as well as an Authorization header. Only one of those would be necessary. I’m not 100% certain how Forgeops is configured, but on a standalone IDM 7.3 you can just use the X-OpenIDM-* headers. This does however lead to the next item…
  2. While you’ve redacted the value in your Authorization header, I see you used the Basic auth scheme but indicated you were passing in a token (presumably an OAuth2 access token from AM). If that is the case, you would use the Bearer auth scheme in the header. This is hinted at from your response, which contains a www-authenticate response header stating that it wants you to use the the Bearer auth scheme.

I’d suggest exploring both of these options and then tailoring your solution towards the use case that best suits your needs.

1 Like
#3

Hi @jiyun_kangh

Also make sure that the configuration is correct:

  • OAuth2 clients configured on the AM side [ Set up AM :: ForgeRock Identity Platform ]
  • rsFilter configured in IDM [ Set up IDM :: ForgeRock Identity Platform → 6. Change the authentication mechanism to `rsFilter only ]
  • Obtain an access token from AM with the idm-admin-ui OAuth2 client
  • Introspect the access token - to verify the subject correlates with the subject mapping in the rsFilter configuration
  • Follow @mwtech instructions to issue the REST call to IDM

Regards
Patrick

1 Like
#4

@mwtech @patrick_diligent I really appreciated your help!

I applied what both of you had recommended and now I am getting 403 error instead.

Here is how the access token look like from the IDM admin UI login request.

image
image1528×252 75.2 KB

And here is how the IDM REST API responded with the 403 error. Could you have a look?

curl --location 'https://{{hostdomain}}/openidm/managed/user?_prettyPrint=true&_queryId=query-all-ids&_totalPagedResultsPolicy=NONE#1.0_query_id_query-all-ids' \
                                                                         --header 'Accept-API-Version: resource=1.0' \
                                                                         --header 'Accept: application/json' \
                                                                         --header 'X-OpenIDM-Username: {{adminuser}}' \
                                                                         --header 'X-OpenIDM-Password:{{password}}'
*   Trying 34.36.211.245:443...
* Connected to {{hostdomain}} port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
* Server certificate:
*  subject: CN={{hostdomain}}
*  start date: Aug 22 18:13:13 2023 GMT
*  expire date: Nov 20 19:06:06 2023 GMT
*  subjectAltName: host "forgerock.idpingress.net" matched cert's "{{hostdomain}}"
*  issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1D4
*  SSL certificate verify ok.
* using HTTP/2
* h2 [:method: GET]
* h2 [:scheme: https]
* h2 [:authority: {{hostdomain}}]
* h2 [:path: /openidm/managed/user?_prettyPrint=true&_queryId=query-all-ids&_totalPagedResultsPolicy=NONE]
* h2 [user-agent: Mozilla/5.0]
* h2 [accept-api-version: resource=1.0]
* h2 [accept: application/json]
* h2 [x-openidm-username: {{adminuser}}]
* h2 [x-openidm-password: {{password}}]
* Using Stream ID: 1 (easy handle 0x12080d800)
> GET /openidm/managed/user?_prettyPrint=true&_queryId=query-all-ids&_totalPagedResultsPolicy=NONE HTTP/2
> Host: {{hostdomain}}
> User-Agent: Mozilla/5.0
> Accept-API-Version: resource=1.0
> Accept: application/json
> X-OpenIDM-Username: {{adminuser]}
> X-OpenIDM-Password:{{password}}
> 
< HTTP/2 403 
< date: Fri, 22 Sep 2023 17:34:53 GMT
< cache-control: no-store
< content-security-policy: default-src 'none';frame-ancestors 'none';sandbox
< content-type: application/json;charset=utf-8
< cross-origin-opener-policy: same-origin
< cross-origin-resource-policy: same-origin
< expires: 0
< pragma: no-cache
< x-content-type-options: nosniff
< x-frame-options: DENY
< content-length: 75
< x-envoy-upstream-service-time: 11
< server: envoy
< x-envoy-decorator-operation: idm.forgerock.svc.cluster.local:80/*
< via: 1.1 google
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
< 
{
  "code" : 403,
  "reason" : "Forbidden",
  "message" : "Access denied"
* Connection #0 to host {{hostdomain}} left intact
}⏎
#5

Hi @jiyun_kang

I see you are passing the X-OpenIDM-Username and X-OpenIDM-Password headers in your request. Since you have acquired the access token from AM and presumably set up your environment as @patrick_diligent suggested, you should be using that bearer token in your requests. Can you try removing the X-OpenIDM-* headers from your request and replacing them with an Authentication: Bearer <token value> header, where <token value> represents the value of the access token returned from AM?

2 Likes
#6

Thank you @mwtech and @patrick_diligent. Using the bearer token from IDM admin UI instead of user credential works great.

3 Likes
#7

One last point @jiyun_kang, to access the IDM admin console, don’t forget to set up ui-configuration.json - this indicates to the login UI which OAuth2 client it should use. Then direct your browser to the login UI, and once in the dashboard, you can launch the IDM admin console

2 Likes