Rules and Hooks nearing End of Life

Hey there everyone!

First and foremost thank you for asking those questions and of course we understand your concerns. My name is Konrad and I’ll be advocating and being your bridge between you and our product team responsible for deprecating this part of our stack.

We will be gradually providing you with answers to your questions. Thank you for your understanding and please gather all those questions in this thread here so we can have them in a single place. Thank you!

1 Like

Hello,

Considering that Rules/Hooks are coming to their end-of-life, what is the recommended way to keep supporting the Account Linking feature?

Thank you in advance,
Giordano

3 Likes

I just created my first rule yesterday! :joy:

I too am concerned that there are gaps in the Actions implementation at the moment. According to this thread: Cannot Access Mapped SAML Properties inside Custom Action the only way to map custom SAML attributes into a user’s app_metadata is through a Rule. Losing this functionality will prevent our application from reading the roles sent by our customers’ IDPs.

Is the actions limitations page the only location to see the current gaps? Are there any plans to list gaps with expected migrations? Do you expect all gaps to be eliminated at EOL?

5 Likes

To add to the chorus, we absolutely need access to the custom IdP data before we can move entirely to Actions. Many of our clients have 1 or even 2 different Enterprise Connections to implement SSO with our application, and often custom data is passed to us that we need for determining the proper roles.

Any other solution (like having our app use the management api to pull data off of the user object) would introduce a lot more complexity and latency to the process. If this data is being passed as part of auth, it feels reasonable to be able to access it in the action.

5 Likes

I’m chiming in as well so I can be aware of progress. We alter SAML mappings for one of our applications and right now this can only be done in Rules. Thank you!

1 Like

Would like to reiterate what other commenters have said about data from third-party IDPs. I currently use a Rule to pass data from the access token received from the third-party IDP into the access token generated by Auth0. Currently no way that I know of to do this with Actions. How to set app roles/permissions directly in enterprise IDP

3 Likes

We also depend on using Rules in cases where Action cannot be used - such as accessing user properties that were created from claims. We also use a rule for preventing authentication for a local database account if a user’s email is not verified as per the example videos. I’m not sure if this can be achieved using an Action or not.

I really enjoy the actions feature, but we still depend on rules as per your recommendation to access e.g. AzureAD properties from a user.
So i am irritated, that you deprecate the rules feature, but not having a possible alternative for it.
We need a -short, near- timeline that you add this as feature in actions, otherwise your timelines are not acceptable in a enterprise environment. you should only start a deprecation timeline, when your features are ready.

2 Likes

Thank you. Just to put it out there, while it is understandable that not everything is figured out on your end yet, hopefully the answers won’t be TOO gradual. At first glance, a year and a half seems like a long time, but say there is some technical limitation on your side that prevents the IdP values coming through to actions, and there isn’t an alternative way to handle it.

If we had to actually move off of Auth0, that’d be a big ordeal. Not just in terms of code we’d have to change (are using the nextjs-auth0 library, the management api for different purposes, liquid templates on the login screen), but needing to manually coordinate with many different clients. In theory, we could re-use enterprise connections due to having our own auth domain name, but would need a lot of testing in practice, especially to do a changeover without downtime.

Obviously, if support is coming before the EoL, we don’t need the exact details of the syntax right now. But if there is any chance that it won’t be implemented at all, we’d need to know as soon as possible.

1 Like

We need to convert saml mapping rules to actions

Hi,

TLDR My wish list:

  • Allow importing user Social identities
  • Allow Actions to switch users
  • Allow Actions to link users
  • Allow specifying default Auth0 Roles or allowing Actions to set Auth0 Roles

we have a few cases where we HAVE to use rules.

First case: Automatic link of Social login and DB user with same email.
We could only migrate the existing users from our IdP provider as DB users. Migrating the SSO identity is not supported in Auth0. Any user that attempted to log-in with Social would get a new Auth0 user, without the migrated roles/permissions/metadata.
So we have a rule that does an email user search (possible mgmt API rate limiting issues!) and if it the Social email and the DB email match we link them so that the DB user is primary and we get to keep the migrated data.
And then as the last step we set the context.primaryUser to the DB user so the token is generated for that one and not for the Social user/identity one.

Second case: Assign default role to the User on first log in
Here I mean the Auth0 Role, with permissions to APIs, also no metadata and custom claims. Here we need the real deal so we get the proper permissions.
There are a few tutorials here how to do this in the post-registration flow with actions but that is only for DB users signing up. Social login users skip the post-registration flow AFAIK and they are not assigned the role.
So we have a rule that checks if the user is logging in the first time (context.stats.loginsCount) and assign him the default role(s).

Third case: Get all user permissions for all APIs
Our current IdP will always provide the full set of resource/permission combinations for the user logging in. That way the token could be forwarded by the UI to API1 and API2 and both would have the permissions for them available in the token.
We have a rule to fetch all the permissions for the user and add them to the token scope.

Can any of these be solved by Actions currently?
Will the generated token at the end have all the identities and permissions that we changed in the action?

We are going to migrate from Rules/Hooks to Actions, but we faced a problem.
Currently, we send requests from Auth0 Rule to some external API. This external API requires authorization, so we generate M2M token (expires in 24h) and we store that token in Rule variables (“configuration” object). Basically, we use “configuration” to cache our tokens.
I do not see a similar option in Actions. There are Secrets, but they are read-only. We need a place outside the Action to store some information, information should live there for at least 24h (api.cache is not good for this), and different sessions should have access to this place.

We have trust configured Idps And I have rule for Automatic account linking on first login… That works how it is required…

But now the Rules ends on November and there is no replacement for Actions for account linking…

Currency in rules I manually link accounts… But if this is not supported by actions what i should do? This is key feature since we use custom DB where only one account per email can be created…

From Docs:

Actions does not currently support:

Account linking

1 Like

Hey there everyone! Got an update for you as I gradually group those questions and get answers from the team behind the deprecation. Here it is. Let me know your further questions!

  1. Account Linking not doable through Actions. Should users manually update the extension to support Actions and if we will eventually create a new Action based alternative for that?
  • Account linking as a parity gap is being assessed and will be addressed before Rules Removal
  1. Copying user object from rule into the user_app_metadata so the customer can access this information in Action (event.user object does not include all the custom Idp attributes)
  • Copying user object from rule into the user_app_metadata so the customer can access this information in Action: We are woking on root-level user attributes to address this.
  1. Altering / converting SAML mappings
  • SAML mappings as a parity gap is being assessed and will be addressed before Rules Removal
2 Likes

I heard that rules/hooks are going to be deprecated (Auth0 Rules), which may lead to the account link extension (Account Link Extension) rules becoming obsolete. I would like to know if there are plans to address this issue or provide alternative solutions from the official side.

“parity gap is being assessed and will be addressed before Rules Removal” across the board is not an update that inspires confidence.

When will timelines be available? Will the replacements be rolled out before hard deprecation in Nov 24 or before rules are removed from new tenants in Oct 23?

1 Like

What about the Authorization Extension will that be deprecated alongside Rules or will it be updated/supported?

If it’s getting deprecated too are you adding Groups support to the core Auth features?

1 Like

Yes it’s gonna be addressed you can check the response here:

Hey there @kieran.mann !

Following up on that with the team!

1 Like

We’ve already moved everything we could on actions, however, your rules’s deprecation notice without providing at least the SAME functionality on actions is a HUGE problem for us.

Problem: rules allow account linking via API and switching context for the right linked user using context.primaryUser (see Context Object Properties in Rules, Context Object Properties in Rules). Actions do not (as for today). This is a huge pitfall and must be addressed by you

The problem is the same as the one described by fran.pregernik here above:

First case: Automatic link of Social login and DB user with same email.

Here are some posts from other users which have the same problem:

“changing the user context as described here apparently relies on now-deprecated functionality from the v1 programming model for the PostLogin trigger. As it stands today, only the context.primaryUser method works to change the primary user (see Context Object Properties in Rules for more details), and this only works within a Rule context.”

So what we should do? It is clear that we expect from you that Context Object Properties in Rules Context Object Properties in Rules need to have a similar alternative with Actions, with context.primaryUser working on actions as it is now with rules (at least as it used to work with actions in 2021!).

You have paying customers relying on this functionality now in Production.
It is fine to set a deprecation notice on rules, but at least you need to provide an easy to migrate option with Actions, without asking us to re-implement all auth flows!

When this functionality will be restored on Actions (it used to work in 2021)?
Can you provide an ETA?

1 Like