@jan-1 , unfortunately I don't have a great suggestion for you. It looks like @robotdan is taking a look at the issue you created. I will follow the issue and check back in, once they update it.

@impackt Great, glad you have a path forward.

You want to look at https://fusionauth.io/docs/v1/tech/lambdas/samlv2-response-populate/ This can update the email/nameId before it is sent over to the special SP.

You will want to create a separate application and set the Response Populate Lambda to the lambda which does this transformation. This can be done via the UI as illustrated here: https://fusionauth.io/docs/v1/tech/samlv2/

Use the managed domains feature. From the docs:

Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.

Documentation:

https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/

This also works with an OIDC provider and from tenant to tenant in the same FusionAuth instance. Assume you have an app (app1) in your existing tenant and you want to allow users in a different tenant to log in to app1. You can do this with an identity provider.

To do so:

create a new tenant in your FusionAuth instance create an application in the new tenant (app2) add an authorized redirect URL of https://yourinstance.fusionauth.io/oauth2/callback make sure the authorization code grant is checked. create a user in the new tenant use same email address but a different password register the user for app2 create an OIDC identity provider the name should be app2 IDP update the button text to say 'log in with app2 in a different tenant' the client identifier and secret should be the app2 client id and secret the scope should be openid profile email the authorization URL should be https://yourinstance.fusionauth.io/oauth2/authorize the token URL should be https://yourinstance.fusionauth.io/oauth2/token the userinfo URL should be https://yourinstance.fusionauth.io/oauth2/userinfo enable the OIDC identity provider for app1 and make sure to create a registration for that application when a successful authentication is done.

When you visit the app1 login screen, you should now see a button prompting you to log in with app2.

This allows you to do cross tenant enterprise sign on within the same FusionAuth instance.

Nope. While you can modify attributes of the user object and the changes will be persisted, you can't modify the registrations of that user.

@trevorr said in Is it possible to create a user without a password?:

Would changing this be a reasonable feature request?

Sure, seems reasonable to me.

I'm not quite sure of the ramifications because the identity providers are assigned at the application level and users are a tenant scoped entity, but I suppose you could just say that any user marked with a 'nolocalpassword' attribute would not be able to ever log in locally. They'd always have to be authenticated by a third party system. I haven't thought through all the ramifications but think this would be a fine feature request. Please file away 🙂 : https://github.com/fusionauth/fusionauth-issues/issues

Note that the random password example in that other thread might fail sporadically because there's no guarantee that a base-64 string will contain a "special character".

Maybe I misunderstand you here, but that's a matter of the password rules and the random string generation, correct? You could set up random long strings and make sure they included non alphanumeric characters. Should be a library for that (here's one for java). Or you could relax your password rules to allow for only alphanumeric characters (this may or not make sense, depending on what kind of users you have logging into the tenant).

While FusionAuth supports both well, if you have the option to use SAMl v2 or OIDC, I would always recommend OIDC.

In general, it is much much simpler to use, debug, configure, etc.

We don’t currently support IdP initiated login.

This has come up a few times, we’ll likely end up adding it, but for now it is not possible. We have an open feature for this in GitHub.

Please feel free to upvote it or otherwise communicate your desire for this work to be done.

@jbradford Another option, is if you're on the login page, you can add &showPasswordField=true to the URL and that should render the login form with the option to add a password.

Related GitHub issue: https://github.com/FusionAuth/fusionauth-issues/issues/995

Awesome! I know this is on our minds, but don't have an exact timeline for when it'll be implemented.

We don't support this functionality at this time.

Pulled over from https://github.com/FusionAuth/fusionauth-issues/issues/700

This is a CORS error. You'll need to ensure POST is an allowed HTTP method, and the origin of your SAML IdP is configured as an allowed origin.

https://fusionauth.io/docs/v1/tech/reference/cors