Blaine Ott

Wim, the JWT that is returned from the direct curl using the code from the verify log is exactly what we get from our public servers. I do have to export that JWT to another machine because I can't get to https://jwt.io from the server. Also, like our public servers, we're using OIDC flow. I'm not that familiar with the dev tools, but watching the network tab shows pretty much what is shown in the IIS log. Nearly immediately, there is a call to the https://tts-fm-pdb2.trinity.duke.edu/oauth/redirect?code=XXXXXX&state=<long_string>. On our public servers, that call to the same, server appropriate link, is very quickly verified, where the private server takes about two minutes before failing to verify.

We have successfully implemented OAuth integration into a couple of our FileMaker servers with our custom IdP. We're now hoping to implement it on server in a heavily restricted network. We have allowed traffic in and out on 443 between the FileMaker server IP to our IdP IP, but we can't get a successful verification of our custom IdP. When clicking the Verify Your Identity Provider, we are sent to our IdP to authenticate and then after a successful login and releasing the information, the browser spins for 120 seconds, then the browser URL switches to a local FileMaker server address and sits for another 30 seconds before reporting failure saying the access token or ID token cannot be retrieved. It feels like some necessary traffic communication is being blocked and eventually timing out. We can visit the Authorization Code Endpoint address directly (that includes the Client ID and Client Secret along with the servers oauth/redirect address) and get a code. Using that code, we can use a curl command to the Authorization Token Endpoint address and get JWTs for both an ID and an Access tokens, all within a couple of seconds. Is the FileMaker server looking for traffic on an additional port to complete the transaction or translate the JWT from the IdP? The IIS logs suggests FMS is getting the code from our IdP, but hitting an error 25022 trying to verify the response: 2022-10-31 04:04:03 10.136.150.14 GET /fmi/admin/internal/v1/extauth/getoauthurl provider=General&trackingID=3b6c5364-b919-4c29-ac0c-1c7fb0256e7d&address=tts-fm-pdb2.trinity.duke.edu&X-FMS-OAuth-AuthType=4&returnURL=https://tts-fm-pdb2.trinity.duke.edu/fmi/admin/api/extauth/oauth-verify&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=a1d6fc12-a5a2-404e-bbf7-46a242a64cf6&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://tts-fm-pdb2.trinity.duke.edu/admin-console/app/administration/externalauthentication 200 0 0 3048 2022-10-31 04:04:03 10.136.150.14 GET /fmi/admin/internal/v1/extauth/getoauthurl provider=General&trackingID=3776f529-da96-4a1a-9a8e-6492a3fcee62&address=tts-fm-pdb2.trinity.duke.edu&X-FMS-OAuth-AuthType=4&returnURL=https://tts-fm-pdb2.trinity.duke.edu/fmi/admin/api/extauth/oauth-verify&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=aa7b851b-4fef-4b1a-bc63-71094bce9a78&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://tts-fm-pdb2.trinity.duke.edu/admin-console/app/administration/externalauthentication 200 0 0 2600 2022-10-31 04:06:34 10.136.150.14 GET /oauth/redirect code=enA7mZ&state=WC1GTVMtUmVxdWVzdC1JRD1GNkU1MEJFNTMwODVCRUM2QjI4MDFCMUJCNTAyRkQ0NA%3D%3D.WC1GTVMtT0FVVEgtUHJvdmlkZXI9RHVrZU9BdXRo.WC1GTVMtT0F1dGgtQXV0aFR5cGU9NA%3D%3D.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vdHRzLWZtLXBkYjIudHJpbml0eS5kdWtlLmVkdS9vYXV0aC9yZWRpcmVjdA%3D%3D.&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=bf36b5e5-d157-4d64-9c9f-fbafc7056152&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://oauth.oit.duke.edu/ 200 0 0 122281 2022-10-31 04:06:34 10.136.150.14 GET /fmi/admin/api/extauth/oauth-verify trackingID=3b6c5364-b919-4c29-ac0c-1c7fb0256e7d&identifier=-1&error=25022&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=ab6302f0-8a37-4f60-879a-283809e7da5b&SERVER-STATUS=200 443 - 10.136.150.14 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/106.0.0.0+Safari/537.36+Edg/106.0.1370.47 https://tts-fm-pdb2.trinity.duke.edu/oauth/redirect?code=enA7mZ&state=WC1GTVMtUmVxdWVzdC1JRD1GNkU1MEJFNTMwODVCRUM2QjI4MDFCMUJCNTAyRkQ0NA%3D%3D.WC1GTVMtT0FVVEgtUHJvdmlkZXI9RHVrZU9BdXRo.WC1GTVMtT0F1dGgtQXV0aFR5cGU9NA%3D%3D.WC1GTVMtUmVkaXJlY3QtVVJMPWh0dHBzOi8vdHRzLWZtLXBkYjIudHJpbml0eS5kdWtlLmVkdS9vYXV0aC9yZWRpcmVjdA%3D%3D. 200 0 0 10

Tomy, unfortunately as this white paper, https://fmforums.com/files/file/115-how-to-extend-oauth/, suggests, the response to that function seems to be hardcoded to the email claim. However, it makes sense to us that it should be related to the Custom IdP User Schema as well. In our IdP, not every account has an email claim, emails are not necessarily unique and can be easily changed. We were hopeful this would be updated or at least made an option in 19.5.1, but that doesn't seem to be the case.

What is that 3rd call FMS is making? Is that to the Authorization Profile Endpoint URL? Based on Duke's documentation at https://authentication.oit.duke.edu/manager/documentation/oauth/overview.md, we've be using the userinfo URL for that entry in our config. As you see from above, we don't get group claims in the response to that call. The documentation suggests that, by default, we can get the groups claim in the id_token, the access_token and/or using the Introspection URL and I've seen that in all three cases. Here's what we get out of a call to the Introspection URL: curl -u '<client_id>:<client_secret>' https://oauth.oit.duke.edu/oidc/introspect -d 'token=<access_token>' {"active":true,"scope":"groups openid email","expires_at":"2022-02-25T13:30:56-0500","exp":1645813856,"sub":"user@duke.edu","dukeNetID":"user","dukeUniqueID":"#######","email":"user_email@duke.edu","user_id":"user@duke.edu","client_id":"<client_id>","token_type":"Bearer","azp":"<client_id>","groups":["tts-fm-oauth-test"]} I've tried testing with using the Introspection URL as the Profile Endpoint URL and OAuth, but all attempts at verifying fail and suggest ensuring "correct information in the Authorization Profile Endpoint field." Do we need to see if we can get the groups claim in the Userinfo response? Or is there something else in the Oracle Identity Cloud Service white paper we're missing? We'd definitely be interesting in looking at that.

I've asked Duke what their implementation of OAuth they are running. Would their openid-configuration help? https://oauth.oit.duke.edu/oidc/.well-known/openid-configuration The id_token does not contain those other properties, but I can pull them, depending on which scopes we release in our client registration, with an access token: curl https://oauth.oit.duke.edu/oidc/userinfo -d 'access_token=XXXX' {"sub":"<user>@duke.edu","dukeNetID":"<user>","dukeUniqueID":"#######","dukePrimaryAffiliation":"staff","name":"<First Last>","given_name":"<First>","family_name":"<last>",""email:"<user_email>@duke.edu"} One thing we've found with our current configuration is we can authorize users via group membership using OIDC and User Account Schema as sub, but we get no user for the function Get(AccountName). Looking at your White Paper, How To Extend oAuth2 Functionality In The FileMaker Platform—Version 1.0, on page 10 it says "The claim for “email” or “unique_name” is used for the Get(AccountName) function." Other places it suggests it is using email. Is there anyway to change that configuration to use a different property? Shouldn't it use the User Account Schema property? I've asked Duke if we can get a customized id_token, but I suspect they aren't including it by default because not every account in the system has an email address set, like service or test accounts. Email address is also not guaranteed to be unique, which is why Duke has standardized on eduPersonPrincipalName (user@duke.edu) as it's unique identifier. If there is no way to change the configuration for the function, is there another function that we could use to pull the sub value? We have some databases that show different views based on username as well as logging database changes that currently use the value of that function.

Wim, for our IdP, we are using an internal OAuth instance that Duke's Identity Management group has configured for its users and groups created in our Grouper instance. Their brief documentation lists their openid scope "provides sub, dukeNetID, dukeUniqueID. sub is the user's eduPersonPrincipalName (or \<netid\>@duke.edu)." However, after a bit more flipping of switches in the configuration, sub may be the missing config after all. We had never got a successful verified IdP using the OpenID Connect (OIDC) option, only the OAuth 2.0 option in the Custom IdP configuration. However, I think we had always tried dukeNetID as the User Account Schema. Thanks to your suggestion, using sub for the User Account Schema did allow us to successfully verify with the OIDC option and that configuration has finally granted me access via group membership to our test database. Thank you so much for your help with this! This has been a slow six week process because we can only get our IdM team's attention about once a week and their documentation is pretty sparse, so we've been trying to reverse-engineer two black boxes to talk to each other. I think we're finally have something we can test with!

Wim, we have had problems getting in place upgrades to work with point releases of 19 not retaining our admin logins and have had to do full uninstall/reinstalls to get the server updated. After the move to 19.4, we noticed after the last one that Windows 2012 R2 is no longer a supported OS and plan to move to a newer OS. As for the configuration, the openid scope we're using in addition to the groups scope provides sub (username@duke.edu), dukeNetID (username) and dukeUniqueID (an intenral unique number identifier.) We have been using dukeNetID and that has allowed us to authorize individual users via OAuth. Changing the value for the User Account schema changes the listing in the successful Verify IdP message. (You are currently log in as user vs user@duke.edu vs #######.) We've now configured the User Account Schema to sub along with the User Group Schema to groups, but still no luck authorizing via group membership. We'll start our server migration to 2019 but we'd be interested in any logs we could look at or other troubleshooting we could perform.

Hi, we are running FileMaker Server 19.4.2.204 on Windows 2012 R2 and are having problems authorizing our instance against our university's in-house OAuth IdP. We've been able to get individual users authorized but are having no success getting authorization for groups. By visiting https://<Authorization Code Endpoint>?response_type=code&client_id=<Client ID>&state=your_opaque_state&redirect_uri=https://<server>/oauth/redirect we've been redirected to a page that includes a session code. Using that code, together with the Client ID, Client Secret, Authorization Token Endpoint can curl an access token. The decoded JWT id_token returned suggests we are getting group claims from our IdP: { "sub": "<user>@duke.edu", "aud": "<Client ID>", "kid": "rsa1", "iss": "https://oauth.oit.duke.edu/oidc/", "groups": [ "tts-fm-oauth-test", "tts-fm-desktop-oauth" ], "exp": 1645417130, "iat": 1645416530, "jti": "b51a502f-b62a-4f7b-9d17-f39f0d44de69" } However, our attempts to grant those group names access do not grant us access to the database in Web Direct. In the OAuth configuration, we have tried using groups for the Custom IdP User Group Schema as well as leaving it blank. We can successfully Verify Our Identity Provider and the message will report "You are currently login as <user>." (That user name will change depending on what property we configure for Custom IdP User Account Schema.) Any suggestions for what we should use for the Group Schema value? Any other troubleshooting we can investigate as there doesn't seem to be much in the default logs that we've been able to find to point us in the right direction? Blaine Ott Duke University