OAuth integration with custom provider troubleshooting

[Blaine Ott]

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

[Wim Decorte]

First off: FMS 19 is not supported on Windows Server 2012, incompatibilities typically first show up in web-related aspects of FMS, and Oauth definitely uses IIS on the way in.

https://support.claris.com/s/article/FileMaker-Server-operating-system-requirements-all-versions-1503692927810?language=en_US

Not saying using a supported OS will fix this for you but it is absolutely the very first thing you need to do.

 

Your JWT does include the groups as FMS expects them to and you don't need to change the Group Schema value, just leave it as 'groups', but the JWT does not contain the typical 'email' key for the user.  The user is in 'sub'.  So if you are using 'email' in the User Account schema then it won't work.  You need to use 'sub' there.  FM still needs to be able to uniquely identify the user before it lets someone in the solution.

Edited February 22, 2022 by Wim Decorte

[Blaine Ott]

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 ([email protected]), 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 [email protected] 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.

[Wim Decorte]

2 hours ago, Blaine Ott said:

As for the configuration, the openid scope we're using in addition to the groups scope provides sub ([email protected]), dukeNetID (username) and dukeUniqueID (an intenral unique number identifier.) 

I don't see that in the JWT you posted... if it is in there, then make sure to provide all relevant info otherwise you're leading us on a wild goose chase I'm afraid.

There are no logs to look at, FMS just reads the id_token JWT and looks for the schema elements as defined in the FMS config.

Unless your flow is not OIDC but a full OAuth2 that requires a 3rd call to the userinfo / profile endpoint.  What's the underlying IdP?

 

 

 

 

[Blaine Ott]

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 Decorte]

6 hours ago, Blaine Ott said:

using an internal OAuth instance that Duke's Identity Management group has configured

The question was about what they are using for this.  OAuth is nothing but a concept, implemented by tools and software.  Knowing what tool they use can go a very long way towards understanding how the OAuth and OIDC principles are implemented because many implementations are opinionated and will make you do certain things a certain way, different than other implementations.

They could be using Red Hat's Keycloak, AD FS, Oracle ICS, Auth0, Ping, Okta,... any number of implementations.

 

6 hours ago, Blaine Ott said:

Their brief documentation lists their openid scope "provides sub, dukeNetID, dukeUniqueID.

Clearly it doesn't because the id_token JWT contains neither dukeNetID nor dukeUniqueID... so the documentation isn't accurate.  Which is tough.

[Blaine Ott]

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 ([email protected]) 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 Decorte]

13 hours ago, Blaine Ott said:

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:

That makes the flow an OAuth2 flow and not an OIDC flow.

 

13 hours ago, Blaine Ott said:

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).

Yes - we've seen that too.  It's a sign that you should use the OAuth2 flow and not the OIDC flow.  That means that you may have to adjust both the user account schema and the group account schema on the FMS side, so that it reads what the 3rd call (not the id_token call) returns.

 

14 hours ago, Blaine Ott said:

Is there anyway to change that configuration to use a different property?  Shouldn't it use the User Account Schema property?

On the FM side, you can only adjust the User Account schema and the Group Account schema.  And you have to set it based on what the IdP returns.  You almost never have control over what the IdP sends.

In your case, switch FMS to the OAuth flow and adjust the user and group schema to read from what that 3rd call returns.

We have a blog post that is about to be released that describes this process for Oracle's Identity Cloud Service.

[Blaine Ott]

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":"[email protected]","dukeNetID":"user","dukeUniqueID":"#######","email":"[email protected]","user_id":"[email protected]","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.

[Wim Decorte]

Yes, the 3rd call is to the UserInfo endpoint, often also called the Profile endpoint.

I have not come across an implementation yet where the data is mixed like here; where some of it is in the id_token and some in the profile.  Usually in scenarios like yours, only the basic stuff is in the id_token and it is not used because setting FMS to OAuth just uses the access token from the 2nd call to make the 3rd call and retrieve the user's profile data.

If your IdP can make sure that all relevant data is reported in the profile json then that would fix this whole thing.