Resource Paramter in Oauth authentication is not working

Question

The authentication to IFS should be handled via Active Directory Federation Services (ADFS). For this system, which had been prepared already for the usage Customer is now using ADFS authentication for the windows users.

Some software, for example some handheld scanners or some other software need to use own IFS Clients developed by the customer to connect. And these need to use ADFS.

Most of these are handled via java applications or via Postman.

For testing purposes with Postman the customer has tried to receive an Access Token from ADFS which should be used to authenticate to the IFS system.

Had been tested via OAuth2 Flows “Authorization Code” and “Resource Owner Password” as documented in the technical Docs.

The parameter resource had been set as well with the value “api://PTY10”.

You can see in the following picture that an error is displayed when the “Resource Owner Password Flow” is configured.

{

"error": "unauthorized_client",

"error_description": "MSIS9605: The client is not allowed to access the requested resource."

}

Unfortunately, the customer had not been able to solve this issue.

From his point of view, the call should be correct.

When using different parameters („resource“ / „client_id“ / „client_secret“ / „password“) the error message changes.

Not using the parameter resource displays a 401 message from IFS.

Maybe the ADFS Server is configured in a wrong way?

What the customer had tested first:

Using the Resource parameter with value „ifs-pty01.me-group.local:51080“ instead of „api://PTY10“ you receive a token from the ADFS Server.

With this token, only the error message 401 is received.

IN addition to that, Troubleshooting Detailed ID Asserter Logging had been acitivated in the MWS.

In this message you can see the following

commons.exceptions.OpenIdAssertionFailureException: Details: Expected: "api://PTY10". Found: [ifs-pty01.me-group.local:51080]..

This implies that the resource has to be set to “api://PTY10”. But this is not accepted by the ADFS Server.

Any suggestions on that?

icon

Best answer by TobiasKellner 25 May 2022, 14:24

View original

TobiasKellner · Accepted Answer

CORRECTION OF MY LAST ANSWERAfter I figured out a lot more about OAuth2 and I think I am understanding now how the Client Credential Flow and the Resource Owner Password Flow are working.As I mentioned in my last answer there are two different ways to authenticate:"native"/"public": Without Client-Secret"web"/"confidential": With Client-SecretThe reason why these two ways exists is explained here: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkceAnd tocorrect my last answer:It doesn`tmatter if you use the public login or the confidential login. Both are working for the WebAPI.SOLUTIONThe point where I was getting confused by the documentationwas at the following line:Give an Identifier. For documentation purposes giving the application server URL as the identifier is a good idea.If the identifier of this WebAPI is freely configurable, the IFS middleware server cannot know it and thereby cannot set it as theresource parameter in its requests.So I deleted this WebAPI and as expectednothing happend because this WebAPI wasn’t even used.A few lines later the documentation says that we have to create another WebAPI. But now, the identifier must follow the following pattern:api://<INSTANCE_NAME>So far so good. What I did now, is that I added the“Aurena-Application” to the “Client Permissions” of this WebAPI. So instead of having two WebAPIs, I only have one WebAPI which has configured both the Native- and Aurena-Application (both with the permitted scopes ‘openid’ and ‘user_impersonation’).I did not changeanything inthe configuration of the “Native application” and the “Server application” (“Aurena-Application”). I have also not changed anything on the IFS middleware server.So in my opinionthe documentation is not fully correct.POSTMAN CONFIGURATION FOR PUBLIC & CONFIDENTIAL (MS ADFS & IFS IDP)ADFS ConfidentialADFS PublicIDP ConfidentialIDP Public

TobiasKellner · Answer

UPDATEAs far as we understand it there are two different ways to authenticate for IFS Applications 10:Native: This is used for native applications like the IEE. Since the client runs on the local user machine, in theory a client secret could be acquired by anybody. Therefore only the client id (native) is needed.Web:  This is used for WebAPIs. The client secret is hidden by the backend server and cannot be acquired by anybody. Therefore the client id (web) and the client secret (web) is needed.The same two ways of authentication are available for ADFS servers. This is controlled by the "resource" parameter.Native: api://PTY10Web:  ifs-pty01.me-group.local:51080We now have a test case where we request a native access token from the internal IFS OAuth server.As expected this access token does not work for the WebAPI.If we do the same test case with a web access token from the internal IFS OAuth server we are able to use the WebAPI.So far everything as expected. For the ADFS server we would expect it to work the same way.---------------------------------------------------------------------------In the meantime we managed to get a valid access token for the WebAPIsvia ADFS with the resource parameterset to “api://PTY10” by simply leaving the value for the parameter “client_secret” empty.Unfortunately, as described above, in my opinion it shouldn`t work with the parameter“resource” set to “api://PTY10”as this is the resource value for the “native” applications like IEE.It seems like that there is something mixed up. Instead of getting a valid access token via "api://PTY10", we should have to use "ifs-pty01.me-group.local:51080". Can somebody tell us if our intention is correct, and where we have to change something?In my opinion the ADFS server configuration is correct according to this documentation: https://docs.ifs.com/techdocs/foundation1/040_administration/210_security/015_authentication/030_configure_ADFS/default.htmSo the misconfiguration is probably somewhere in the IFS Middleware Server.We would appreciate any help on this topic.Thanks in advance.

Did you find what you're looking for? If not:

Sign up

Login to the community

Scanning file for viruses.

This file cannot be downloaded