Rules and Hooks nearing End of Life

Community Announcements
, , , ,
1

Hello, everyone! To improve our extensibility offering, we will be deprecating Rules and Hooks as an option for both customers and partners in November 2024 and will be unifying all of our extensibility features under Actions.

We will start removing Hooks access from new tenants/new customers in the coming weeks.

What action do you need to take?

If you’re able to make the migration to Actions now, we highly recommend doing so. To help with the migration process, we have documentation on migrating from Hooks to Actions and migrating from Rules to Actions. We also have a dedicated Move to Actions page that highlights feature comparisons, an Actions demo, and other resources to help you on your migration journey.

Be sure to check out our latest blog on the Rules and Hooks deprecation: Preparing for Rules and Hooks End of Life!

Timeline of deprecation

To give you as much time as possible, we’re announcing this 18 months ahead of the end of life for Rules and Hooks, which gives you into the second half of 2024 to complete the migration process.

Hooks will be removed from all new tenants for new customers and for existing customers starting October 16th 2023 and from tenants for all customers at end of life in November 2024.

We aim to fully remove Rules from all tenants by November 2024. Rules will remain available to all users for the time being, and we will provide a future update on any changes. Existing tenants using Rules will remain active until the end of life in the second half of 2024 but will receive maintenance support only.

Next Steps

Enterprise customers are encouraged to reach out to their Technical Account Manager for any inquiries.

For self-service customers, we would like to hear your questions, concerns, and feedback in the thread below.

Thanks in advance!

6 Likes
2

First off, I’m a big fan of the new actions developer experience! Your team has done a fantastic job on making them easy to implement. The only thing keeping us from fully migrating to actions is that you cannot perform account linking (as mentioned here: Actions Limitations). Are you planning to address this limitation prior to EOL?

1 Like
3

I also like the new actions, but we also have one thing keeping us from fully migrating to actions is that the event.user object does not include all the custome Idp attributes. Currently we copy the user object from the rule into the user app_metadata so we can access this information in the action. I know that this has been on the backlog for some time now. I am hoping you are planning on implementing this in the actions before EOL.

8 Likes
4

We are in the exact same situation. We have a custom claim included in the token from an upstream idp (a partner who onsells our software) and we need to access that custom claim to pass it through to the application. This is currently only possible with Rules.

5 Likes
5

Yes I agree with @james.ernst; we’re new to Auth0 and luckily we’re just starting to implement a rule to access AzureAD groups. So for now we choose to expose those groups using a rule and access them using an action, just as James suggests.
But we really need access to these groups before the EoL…

4 Likes
7

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
8

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
9

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
13

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
14

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
15

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
16

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.

17

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
18

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
19

We need to convert saml mapping rules to actions

20

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?

21

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.

22

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
23

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
24

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.