Inquiry About PAM Authentication Support for iRODS HTTP Client

[Laura Lo Gerfo]

Dear iRODS Consortium Team,

I am writing to inquire about PAM authentication implementation across different iRODS client interfaces in relation to our current project requirements.

We are currently developing a web-based data management portal for our research institution that needs to provide seamless access to iRODS data repositories. Our environment includes a domain-joined iRODS server configured to authenticate users through PAM integration with Active Directory/LDAP.

At present, we are successfully using the Python-iRODS Client with PAM authentication in our backend development. However, we have encountered a limitation when attempting to implement a solution using the HTTP REST API client: it appears to lack PAM authentication capability, whereas this functionality is available and works well in the Python iRODS Client.

I would greatly appreciate your insights on the following questions:

1. Technical Reasoning: Is there a specific technical reason why PAM authentication has not been implemented in the HTTP client interface? Do you believe it would make sense to consider implementing this feature?
2. Alternative Solutions: Are there any recommended approaches or workarounds to enable PAM-based authentication when connecting to iRODS through the HTTP interface in our scenario?

Thank you for your time and for the excellent work on the iRODS platform. I look forward to your guidance on this matter.

Best regards,
Laura

[Terrell Russell]

Hi Laura,

You are the second or third person to now request this - so that means
something!

First I will share with you an earlier thread from a year ago for some
of the answer to your first question about technical
limitations/reasons:
https://groups.google.com/g/irod-chat/c/5VgHOxxtmcs/m/clwAEkK6BQAJ

Second, I'll answer your questions more directly...

> 1) Technical Reasoning: Is there a specific technical reason why PAM authentication has not been implemented in the HTTP client interface? Do you believe it would make sense to consider implementing this feature?

Yes, there was a technical reason, but it has been remedied in the
5.0.0 release of the iRODS server, and will be included in the
upcoming 4.3.5 release. With that said, the HTTP API could soon learn
to sniff the version of the iRODS server it is connected to and offer
a PAM authentication option (in addition to the 'native' and 'OIDC'
options it offers today).

The open issue where this work will be described and implemented is:
https://github.com/irods/irods_client_http_api/issues/265

> 2) Alternative Solutions: Are there any recommended approaches or workarounds to enable PAM-based authentication when connecting to iRODS through the HTTP interface in our scenario?

There is no way to configure the HTTP API to enable PAM-based
authentication today. However, like at the end of the other thread,
if you are already pointing to an AD/LDAP system, those systems
usually offer an OpenID Connect (OIDC) authentication path as well,
and you may be able to configure your HTTP API to use that today.

Please let us know if you get OIDC working, or if you'd be interested
in helping implement and/or test PAM in HTTP API.

Thanks,

Terrell

> --
> --
> The Integrated Rule-Oriented Data System (iRODS) - https://irods.org
>
> iROD-Chat: http://groups.google.com/group/iROD-Chat
> ---
> You received this message because you are subscribed to the Google Groups "iRODS-Chat" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to irod-chat+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/irod-chat/c704e604-5ff9-4843-a8c8-45669caa0cb8n%40googlegroups.com.

[Laura Lo Gerfo]

Hi Terrell,

Thank you for your detailed response and the helpful links.

I’ve attempted to configure OIDC authentication for the HTTP API using Entra ID as our identity provider, and I’d like to share the steps I’ve followed so far.

Application Registration

I registered two applications in Entra ID:

• A Single Page Application (SPA) that acts as the frontend client.

• A second application that represents the protected resource, i.e., the HTTP API.

Scope Definition

In the HTTP API application (the protected resource), I defined a custom scope called irods_access.

Permission Assignment

In the SPA application, I added delegated permissions for the irods_access scope exposed by the HTTP API application.

Token Request

The SPA uses Authorization Code Flow with PKCE to obtain an access token.
The token request includes the following scopes:

openid email profile offline_access api://<http-api-client-id>/irods_access

The access token is successfully issued and includes the expected claims:

• "aud": "api://<http-api-client-id>"

• "scp": "irods_access"

However, when I send a request to the HTTP API using this token, I receive the following error in the logs:

[2025-07-07 13:46:13.221] [P:1] [trace] [T:22] Evicting expired items...
[2025-07-07 13:46:22.286] [P:1] [trace] [T:20] add_asymmetric_algorithm_from_jwk: Detected [RS], attempting extraction of attributes from JWK...
[2025-07-07 13:46:22.287] [P:1] [trace] [T:20] add_asymmetric_algorithm_from_jwk: Adding [RS256] to allowed verification algorithms.
[2025-07-07 13:46:22.288] [P:1] [error] [T:20] validate_using_local_validation: JWT verification failed [token doesn't contain the required audience].
[2025-07-07 13:46:22.288] [P:1] [error] [T:20] resolve_client_identity: Could not find bearer token matching

This occurs even though the token appears to include a valid aud claim ("aud": api://<http-api-client-id>) and the expected scope (."scp": irods_access)

The HTTP API is configured as a protected resource, and I’m using the plugin libirods_http_api_plugin-user_claim.so (though I’m not sure if that impacts audience validation in this context).

---

Questions

• Is the aud claim format (api:// <http-api-client-id>) acceptable to the HTTP API, or does it expect a different value or format?

• Could you provide an example of what the correct openid-connect section in the HTTP API configuration should look like for this kind of Entra ID setup and protected resource?

Specifically, in this configuration—where the HTTP API is acting as a protected resource—what should be set for:

• client_id

• client_secret

• redirect_uri

• require_aud_member_from_introspection_endpoint

Any guidance on this would be greatly appreciated.

Thanks again for your support.

Best regards,
Laura

[Laura Lo Gerfo]

Hi Terrell,

I hope you're doing well.

Just following up to ask if there's anything I might be missing in the current OIDC setup with Entra ID. I'm seeing an audience validation error, even though the token seems correctly issued.

Also, from the README I noticed that only the Resource Owner Password Credentials and Authorization Code grants are listed as supported. Is the protected resource functionality considered stable, or does it require any specific configuration to handle audience validation correctly?

Thanks again for your help!

Best regards,
Laura

[Terrell Russell]

Hi Laura,

> Is the aud claim format (api:// <http-api-client-id>) acceptable to the HTTP API, or does it expect a different value or format?

Yes, right now, HTTP API is following the spec and expecting the exact
string it used for 'aud' as the client-id to be returned. You may be
able to adjust the string returned in the Entra ID configuration
somewhere. This came up earlier with someone else authenticating
through the Azure interfaces, and they were able to manipulate the
returned string formatting.

We are looking into other paths forward - input is welcome. But of
course, we'd like to stick strictly to the specification if possible.

> Is the protected resource functionality considered stable, or does it require any specific configuration to handle audience validation correctly?

Definitely supported, if not already stable... The protected resource
mode will soon be the only mode supported (we are removing 'client'
mode in the next release).
https://github.com/irods/irods_client_http_api/issues/416

Terrell

> To view this discussion visit https://groups.google.com/d/msgid/irod-chat/e29ed83d-6abb-4e21-a54c-901990ebb81bn%40googlegroups.com.

[Terrell Russell]

On behalf of Martin Flores of the iRODS Team... his response since
Google Groups is eating his emails(?)...

> Hi Laura,
>
> An additional option that should work is to set the client_id to include the 'api://' prefix (e.g., api://<client_id_here>).
> In protected resource mode, if your OpenID Provider doesn't have an introspection endpoint (e.g., Azure), then the client_id is only used to validate the 'aud' in the JWT.
>
> To answer the configuration question:
>
> - client_secret
> - Used in client mode and in the introspection endpoint
> - Can be left blank if the introspection endpoint is not used: ""
> - redirect_uri
> - Only used for client mode
> - Can be left blank: ""
> - require_aud_member_from_introspection_endpoint
> - Only used for the introspection endpoint
> - Can be left at the default value if the introspection endpoint is unused
>
>
> If there are any further questions, please reach out!
>
> Best Regards,
>
> Martin Flores
> Software Developer
> iRODS Consortium

[Laura Lo Gerfo]

Hi Martin and Terrell,

Thank you very much for the clarification — everything is working now!

Just a quick curiosity: do the HTTP APIs open a socket connection to iRODS? And if so, under which user account does that happen? Is it using basic authentication with the default rods user?

On the iRODS side, I also have PAM authentication enabled — but I assume the API uses basic authentication regardless?

Thanks again for your support!

Best regards,
Laura

To view this discussion visit https://groups.google.com/d/msgid/irod-chat/CAFaqteau8ktWuz1n_6nJRxjsL67an-L0tsJCfT9e-YSKvPUh3A%40mail.gmail.com.

[Terrell Russell]

Hi Laura,

Can you confirm the steps you took to make it work? And your current
working settings?

The HTTP API proxies the authenticated user to iRODS itself via the
iRODS protocol through the configured rodsadmin account credentials.

// The credentials for the rodsadmin user that will act as a proxy
// for all authenticated users.
"proxy_admin_account": {
"username": "<string>",
"password": "<string>"
},

And yes, correct - the HTTP API does not authenticate with iRODS via
PAM, it's via the native iRODS authentication.

You can read more about the design from the 2023 talk:
https://irods.org/uploads/2023/Draughn-iRODS-HTTP_API-paper.pdf

The irods_client section says...

> This API must be deployed as an administrator since it holds a long-running connection pool with the iRODS server and uses the rc_switch_user functionality to proxy for regular user operation requests (read more in the next section).

Terrell

> To view this discussion visit https://groups.google.com/d/msgid/irod-chat/PA2PR06MB926894B380BCBB0D7099C41A8257A%40PA2PR06MB9268.eurprd06.prod.outlook.com.

[Laura Lo Gerfo]

Hi Terrell,

Thank you for your follow-up. I'm happy to confirm the steps I followed to get the setup working and to share my current configuration.

Azure Entra ID Application Registration

I registered two applications in Azure Entra ID:

• SPA Client App: Represents the frontend (UI), using the Authorization Code Flow with PKCE for user authentication.

• HTTP API Application: Serves as the protected resource for iRODS.

To allow the SPA to obtain a token with the appropriate aud parameter for the HTTP API, I added the "API access as a user" permission from the SPA client to the HTTP API application.

HTTP API – OpenID Configuration

Here is the openid_connect section of the HTTP API configuration:

"openid_connect": {
    "provider_url": "https://sts.windows.net/<tenant-id>/",  --> same as the issuer (iss) value found in the JWT token received during SPA authentication
    "client_id": "api://<http-api-client-id>", -->  'api://' prefix added to ensure proper client ID validation
    "client_secret": "",
    "mode": "protected_resource",
    "redirect_uri": "",
    "user_mapping": {
        "plugin_path": "/usr/lib/irods_http_api/plugins/user_mapping/libirods_http_api_plugin-user_claim.so",
        "configuration": {
            "irods_user_claim": "upn"
        }
    }
}

I hope this configuration is technically correct.
Please let me know if you spot any issues or have further suggestions.

Best regards,
Laura

[Terrell Russell]

This is great validation - thank you.

Excited you were able to confirm and that there were no additional
moving parts needed from our end.

In the next release of the HTTP API, we will ONLY support the
protected_resource mode, so that setting will no longer be necessary.

Terrell

> To view this discussion visit https://groups.google.com/d/msgid/irod-chat/5ab7f92e-3456-4219-9554-848da730ec7cn%40googlegroups.com.