Organization actions - Debug logs
Greetings!
I am trying to figure out how to properly use actions set from organization settings "Actions" tab. In particular, I am setting up a post external authentication action to remap SAML response attributes from an external IdP as attributes for user creation/update. I used the example code provided in the zitadel repo:
https://zitadel.com/docs/guides/integrate/identity-providers/mocksaml#optional-add-zitadel-action-to-autofill-userdata
function map(ctx, api) {
if (ctx.v1.externalUser.externalIdpId != "your_external_idp") {
return
}
// the attribute names below represent the crewjam IDP example, be sure to update them to match your provider info
let firstname = ctx.v1.providerInfo.attributes["urn:oid:2.5.4.42"];
let lastname = ctx.v1.providerInfo.attributes["urn:oid:2.5.4.4"];
let email = ctx.v1.providerInfo.attributes["urn:oid:1.3.6.1.4.1.5923.1.1.1.6"];
let displayname = ctx.v1.providerInfo.attributes["urn:oid:2.5.4.3"];
let username = ctx.v1.providerInfo.attributes["urn:oid:0.9.2342.19200300.100.1.1"];
if (firstname != undefined) {
api.setFirstName(firstname[0]);
}
if (lastname != undefined) {
api.setLastName(lastname[0]);
}
if (email != undefined) {
api.setEmail(email[0]);
api.setEmailVerified(true);
}
if (displayname != undefined) {
api.setDisplayName(displayname[0]);
}
if (username != undefined) {
api.setPreferredUsername(username[0]);
}
}
but I still can't get it to work properly. Trying to debug/see what is wrong with this I noticed there is no action runtime log for actions in Zitadel cloud. I also tried performing an http request sending as POST body whatever info I wanted but it still didn't work. I searched the documentation but there doesn't seem to be anything more than references to the examples. What am I missing? Are these actions v1 or v2? what is the optimal way to debug or test an action?
ZITADEL Docs
MockSAML is not intended for any production environment, only for test purposes
4 Replies
Hi @dokimis, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question.
Answer
Your example action for mapping SAML response attributes matches the official ZITADEL documentation for post external authentication actions (1) . The code you posted is considered an Actions v1 script, as it uses the v1 context (e.g., ctx.v1.externalUser) . The correct way to access the external user in this flow is ctx.v1.externalUser (not as a function) , as clarified in ZITADEL's documentation (2) .
Currently, there is no mention in the official documentation of a built-in action runtime log or direct debugging output for actions executed in ZITADEL Cloud. The documentation provides examples but does not describe a specific debug or test workflow for actions (1) . There is also no documented method for sending arbitrary HTTP POST requests to test actions .
If you need to test and debug actions, you should ensure that your action is correctly assigned to the right flow (e.g., post external authentication) in your organization settings and that attribute names in your script match your IdP's actual SAML attribute names . For further troubleshooting, you may need to rely on your application's behavior or check for user creation/updates that reflect your action's changes.
To learn more, see the sources I considered:
[1] Code examples
[2] Action documentation "External Authentication -> Post Authentication"
Feel free to tag @Ask Inkeep with additional questions.
@Ask Inkeep , following up with some clarifications:
I am using zitadel cloud hosted ui for logging into external IdP via SAML. Authentication flow is done properly but Zitadel upon receiving the SAML response cannot track the attributes required for auto creating and linking the IdP user fields to a new Zitadel user.
I am following this example, for fields provided by a SAML IdP:
/**
* Use SAML attributes from external IDP as attributes for user creation/update
*
* Flow: External Authentication, Trigger: Post authentication
*
* @param ctx
* @param api
*/
function map(ctx, api) {
// if (ctx.v1.externalUser.externalIdpId != "your_external_idp") {
// return
// } // obviously this is commented out so that it is always executed
// the attribute names below represent the crewjam IDP example, be sure to update them to match your provider info
let firstname = ctx.v1.providerInfo.attributes["urn:oid:2.5.4.42"];
let lastname = ctx.v1.providerInfo.attributes["urn:oid:2.5.4.4"];
let email = ctx.v1.providerInfo.attributes["urn:oid:1.3.6.1.4.1.5923.1.1.1.6"];
let displayname = ctx.v1.providerInfo.attributes["urn:oid:2.5.4.3"];
let username = ctx.v1.providerInfo.attributes["urn:oid:0.9.2342.19200300.100.1.1"];
if (firstname != undefined) {
api.setFirstName(firstname[0]);
}
if (lastname != undefined) {
api.setLastName(lastname[0]);
}
if (email != undefined) {
api.setEmail(email[0]);
api.setEmailVerified(true);
}
if (displayname != undefined) {
api.setDisplayName(displayname[0]);
}
if (username != undefined) {
api.setPreferredUsername(username[0]);
}
}
where it is clear that accessing the SAML attributes of the SAML response is done via ctx.v1.providerInfo.attributes.
Thanks for the follow-up, @dokimis. I'll get back to you soon.
Answer
Your approach for mapping SAML response attributes in a post external authentication action matches the official ZITADEL documentation. The example you provided is a direct copy of the recommended pattern for mapping SAML attributes to user fields:
(1)
This script is intended to run as a post external authentication action and uses
ctx.v1.providerInfo.attributes to access SAML attributes, which is the documented way to extract these fields . Make sure that:
- The action is correctly assigned to the flow "External Authentication" with the trigger "Post Authentication".
- Attribute names are correct and match your SAML IdP's response.
- The action is enabled for the correct organization or instance scope (2) (1) .
If you are still experiencing issues with user creation or attribute mapping, ensure your IdP is sending the expected attributes and review your IdP and ZITADEL configuration for any mismatches .
To learn more, see the sources I considered:
[1] Code examples
[2] Configure MockSAML as an Identity Provider in ZITADEL
Feel free to tag @Ask Inkeep with additional questions.
Got it. Tagging @Rajat for additional help.hey @dokimis thanks for your question, I will take a look at it