Posts made by mgetka

Hi FusionAuth community!

I'm preparing an upgrade of a FusionAuth instance embedded in my system. The update is quite a big leap - from 1.33.0 to the latest 1.43.1 version. Across those versions lots of changes appeared, so some tweaks in the runtime environment and supporting services were inevitable, but eventually all is working as expected. With one exception - SSO flow with MFA enabled.

In my system I have a set of independent services that are registered in FA as independent applications. Up until now, our users entered the system by accessing one of those services - the service then redirected the user to complete OAuth2 flow via hosted login pages. If the user decided to navigate to other service, then, the authentication (in the scope of the other service) would be performed without user interaction - since he have an active FusionAuth SSO session the whole authentication drills down to just a bunch of 302 redirects. in 1.33.0, the whole process looked the same with or without MFA enabled, with the exception, that the user was asked for the second factor during the initial sign on (when accessing the first service).

After upgrading the process looks different. The first authentication looks the same, but when the user switches between the services, he is being asked for the second factor - he doesn't need to provide username and password (this is what SSO is all about, yes?) but is being asked to provide second factor on each new service accessed.

The new behavior significantly breaks the UX of my system, and I'm looking for an option that allows to tune FA policies to behave like in 1.33.0. Is this behavior anyhow configurable?

As an additional context I have Multi-Factor policies set to Enabled on the tenant level. The setting is not overridden in any of the FA applications. The whole described journey of a user across all the services happens in the scope of a single web browser session, and without the use of the trust this computer for 30 days option.

When you try to utilize social sign-on in your android application, the page is not loading forever, it is actually being blocked. Redirecting to mobile applications is actually quite tricky. It has been some time since I was working on that matter but I will try to provide with most important insights on the topic.

So mobile app can register pseudo protocol, and once mobile web browser reach url with such schema, the application will be launched. If you register com.company.app as a scheme for your app, and then type in mobile web browser com.company.app://whatever your app will be launched - this works both on iOS and Android. But if you try to assign such url as an OAuth2 redirect_uri it will work on iOS but not necessarily on Android.

The issue is related to chromium security policies on redirects, and since system browsers on android are based on chromium engine it affects web views and other web based modals.

If the user directly types the custom schema url in the browser it will be allowed since the request was directly initiated by the user. If the user logs in via login & password, a chain of events occur (POST request, 302 response ...) that results in a custom scheme redirect, and finally, the redirect will be allowed since direct user action was the initiator of the chain. In the case of social sign on, we could think that the chain leading to the redirect is also initiated by the user, but the magic standing behind the login widgets breaks the chain, and chromium thinks that the redirect was arbitrarily initiated by some scripts rather than the user, so it is being blocked. Here is a link to long living chromium issue if you wish to track how things evolved through the time.

Finally, chromium thinks custom schemas are evil and we need to live with that. But OAuth2 needs to work in todays web, so there is another way - deep linking. Long story short, an application can register some specific URL (with http/https schema) that will lead to opening of the application. Such redirects are not blocked, and indeed it is a recommended way to perform application redirects on android.

So to sum it up, on iOS use pseudo protocol, on android use deep linking with http/https schemas... Nooo, it still not that easy Deep linking is not supported by older android versions, and those older versions allows for pseudo protocol redirects. So if you want to support older android devices that don't receive software updates since some time, you need to use pseudo protocol for them.

So to sum it up (for real this time), on iOS and older androids use pseudo protocol, on recent androids use deep linking with http/https schemas.

In my application, to accommodate the possible combinations, I've chosen to redirect iOS users directly to pseudo protocol. And redirect all the android user to a custom interstitial site. The URL of the site is registered via deep linking, so newer androids will redirect to the app with no fuss. For the older devices, under the address there is a simple page trying to perform redirect to pseudo protocol via javascript. As a last resort, if the user stays on the page for some time (so the javascript redirect didn't succeed), a link like "go back to the app" appears that allows an user to directly initiate the redirect - and this will always works. Example of such an interstitial page can be found at
AppAuth-Demo.

Some additional insights on the matter can also be found in this issue in okta-sdk-appauth-android
repository.

Another aspect in favor of the approach involving API keys is the fact that your application can control the process of data entities modification. To be more precise, your application may implement additional authorization and data sanitization checks. You may prevent a user form changing his user name each day or restrict phone numbers to some country. Notably, many of the FA entities features data attribute that can hold any information. FA has no knowledge of what is the purpose or type of those data, so it has no means of deciding whether to allow an user to change its content or not.

So summing it up - yes, it's up to you to authenticate an user (via JWT validation) and authorize the request, and if everything is ok, to perform the specific API operations with omnipotent API key. It is so, since what does authorize the request mean may be different for each application.

Anything special appears in the logs on startup?

long-string-here is a placeholder for the purpose of the forum post, or is it actually the key you're trying to create? If it is the latter, then it will cause conflict - keys values needs to be unique. If the masterKey variable is also set to long-string-here, then you will end up with only one key created and errors in the logs.

At this point, you may also consider creating a KickStart script that loads the basic configuration with mentioned API keys, groups etc. into a fresh FA installation. You've mentioned that you are working on a test installation, so during the further tests you will probably fill it again with new test data entities. If so, it will most likely be easier to recreate the FA with basic configuration via KickStart, rather than to pick unnecessary entities and delete them one by one. Such script also stands as a good documentation on what configurations has been made to meet your environment requirements.

This post may be a bit off the topic, but from my experience such approach quickly pays off, so you can at once solve your issue and boost up your testing environment ergonomics.

I would consider defining both positions and teams as groups. With such approach one user could have multiple positions - if it is an issue, you would need implement such restriction in your application.

Later on, you define set of granular permissions as roles. The user can obtain a permission (role) in two ways:

• explicitly - the user has specific role set,
• implicitly - the user is in a group (position/team) associated with the role.

$request["user"]["type"] = "admin";

The user entity has not type member. To make such a distinction you can use groups.

You can set registration verification template either via GUI ora API - it doesn't make a difference. Since registrations are application specific, you firstly need to enable application's registrations verification and then you can select the template. Via GUI it can be done in Edit Application > Registration.

But still, at the moment I'm rather confused, and don't really know what are you actually trying to achieve. I suppose that email verification is the only verification that you need, but that is just my guesing.

In the previos post you mentioned 530 error, now it is 503. Also, you haven't provided full trace, so my response was based on some guessing, and the fact that 530 is actually defined in SMTP. On the other hand 503 HTTP code may be returned by the FA on an event of elastic search issues.

503
The search index is not available or encountered an exception so the request cannot be completed. The response will contain a JSON body.

See Complete a Passwordless Login.

Passwordless template is used for passwordless email, so as you are using passwordless login flow, you need this template. This topic, started with the question about email verification, so I suppose you use this feature, and email verification template will be useful as well. As for the registration verification template, as I have recently written:

To sum it up, user entity, created on an user creation event represents an user. This entity contains the user email and its verification status. The user email verification email may be sent only on user creation.
The registration, is an entity that associates already existing user to a specific application. The registration is not related to user email nor its verification status. However, it can contain alternative username to be used by the user in this application only. On an event of registration creation, FA can send confirmation email, but it doesn't confirm user email, it only confirms whether the registration of an user in the application should persist.

So if you want users to confirm registrations in certain applications (in addition to verifying email addresses, which can be understood as account creation verification), configure the functionality, and prepare registration verification template.

530 Authentication required SMTP error means that your tenant SMTP configuration is invalid.

This is a valid result with clear cause described in the docs.

404
The user was not found. The response will be empty.

You need to understand that each tenant has its own, separate user base. So, if the user exists in one tenant, he doesn't necessarily exists in another. Anticipating your question, you cannot have a common user base for multiple tenants - If you want to have single user base, then work on a single tenant.

The code snippet I put in the post where I first mention the withTenantId method is actually such an example. When I recommended referencing the source code, I meant the code itself, not the docstrings - the logic behind the withTenantId method is quite simple, and the code describes mentioned effects (alteration of internal client state) in the most unambigious way.

If you need more verbose examples see the code below

<?php

require __DIR__ . '/vendor/autoload.php';

$apiKey = "5a826da2-1e3a-49df-85ba-cd88575e4e9d";
$client = new FusionAuth\FusionAuthClient($apiKey, "http://localhost:9011");

$request = array(
	"applicationId" => "c9a6f176-93df-4eaa-b67c-b651d18df60c",
	"loginId" => "user"
);
$result = $client->withTenantId("adca656e-4895-4a9e-ac2e-8b9ebebb5149")->startPasswordlesslogin($request);

var_dump($result);

?>

For such a call, the client invokes following HTTP API request

POST /api/passwordless/start HTTP/1.1
Host: [...]:9011
Accept: */*
X-FusionAuth-TenantId: adca656e-4895-4a9e-ac2e-8b9ebebb5149
Authorization: 5a826da2-1e3a-49df-85ba-cd88575e4e9d
Content-Length: 73
Content-Type: application/json

{"applicationId":"c9a6f176-93df-4eaa-b67c-b651d18df60c","loginId":"user"}

The quoted code comment refers to actionUser API method, not the witheTenantId client method.

Referring to the PHP client source code, the tenant id can be set for the client using withTenantId method. Something like this should work:

$client->withTenantId(...)->passwordlessLogin(...);

Be aware that withTenantId stores the id in the client internal state, and the stored id will be used for all subsequent requests. It may be something that suits you or not - refer to the source code and check how this effect will affect your application.

The logout from other devices functionality is based on access and refresh tokens. To implement it, you should configure access tokens to be short lived, and restrict access in your services backend only to users that authorize themselves with a valid access token. Since the tokens are short lived, your applications will require refresh tokens to obtain new access tokens when the old ones expire.

With such preconditions fulfilled, the logout form other devices functionality is all about revoking the refresh tokens provided for other devices. The other devices will still be able to utilize the session, but no longer than access token validity period (that cannot be revoked). Once it expires, they will try to obtain new one using the refresh token but this request will be denied - at this point, the device can be considered logged out.

Some posts ago you have mentioned that both of your apps reside in the same tenant. Moving one of them into another tenant was mentioned but I suppose you have abandoned the idea in the meantime. So, if they are both in same tenant, why would you expect FA to use different tenant ID for each app?

BTW, $this->output->set_header sets the header for a response sent to the web browser - data defined this way will never reach FA.

If you have mor than one tenant defined (as you have) then tenant selection dropdown appears in the application creation view. Create chosen application in the second tenant and discard it in the first one.

I'm glad you got it working! Finishing the topic I will leave few more links:

1. User creation
2. Registration of an existing user in an application.

There is also combined API call, that creates a user and a registration at once - I have missed that saying your register request is invalid - sorry. User creation and registration in one call. This is probably the request you were trying to perform.

You can configure unverified users deletion time in Edit Tenant > Email - as mentioned in my first response. But 5 minute offset is not reachable since the time is given in days.

I believe you are again confusing user creation with registrations. Please refer to the docs for better understanding of the differences.

To sum it up, user entity, created on an user creation event represents an user. This entity contains the user email and its verification status. The user email verification email may be sent only on user creation.

The registration, is an entity that associates already existing user to a specific application. The registration is not related to user email nor its verification status. However, it can contain alternative username to be used by the user in this application only. On an event of registration creation, FA can send confirmation email, but it doesn't confirm user email, it only confirms whether the registration of an user in the application should persist.

You are quoting a code snippet with a register API request, so I suppose you are actually attempting on registration creation, having user creation in mind. The quoted request itself is invalid - the first argument should contain UUID of the user (since registrations are created for users that already exists) so it cannot be successful. This may be the cause of not receiving any emails. If not, you may check your SMTP settings in the tenant configuration. SMTP related errors can also be tracked via System > Event Log.

There is no way to transfer an application from one tenant to another. You must create new application in the second tenant.

You may help yourself with applications API to get json representation of your app, tweak it as needed, and post in another application creation request.

Going back to the original question and external resources synchronization. You may also populate your external database only once the user verifies his email. user.email.verified webhook event can be utilized for such solution.

Long story short, docker-compose is a tool that facilitates running services composed of multiple containers. Personally, I have mixed feelings about snap, and use it only for a limited number of desktop GUI based applications, so I cannot help you with permissions issues. it would be most straight forward just to install docker-compose using the docker provided guide.

I believe that user.delete webhook is being called on an event of automatic unverified user deletion, so you should be able to utilize it for external resources synchronization.