Actions Element

The <actions> element specifies the actual actions to take after a successful SAML response has been received, or a logout has been triggered. Each Action has a LoginAction and LogoutAction, which are executed during those actions. There are four built in actions.

Action	Purpose
SamlPrincipalAction	Sets the SamlPrincipal on the current HTTP context. This is how SAML2 stores the returned attributes from the SAML response.
FormsAuthenticationAction	Handles setting the principal in a FormsAuthentication cookie.
RedirectAction	Handles the redirect after a successful SAML response has been processed using the specified URLs in the ServiceProvider Endpoints, or the returnUrl specified by a MembershipProvider instance prior to initializing the SAML request.
CDCRedirectAction	(Optional) Handles Common Domain Cookie redirects after a successful SAML response has been processed.

Custom actions can be injected into this collection to do other things in your own application as necessary (e.g. using the attributes passed back to look up a local user and log them in via forms authentication, etc.). Any action must implement SAML2.Actions.IAction.

Example:

The below example is the default Action list. If no changes are made here, the "Actions" element can be omitted.

<saml2>
    ...
    <actions>
    <clear/>
    <action name="SetSamlPrincipal" type="SAML2.Actions.SamlPrincipalAction, SAML2" />
    <action name="FormsAuthentication" type="SAML2.Actions.FormsAuthenticationAction, SAML2" />
    <action name="Redirect" type="SAML2.Actions.RedirectAction, SAML2" />
    </actions>
    ...
</saml2>

Creating New Actions

SAML2 allows for the creation of your own Actions that can be injected into the action stream. Normally, this means replacing the FormsAuthenticationAction with a custom implementation, in order to map returned values to local user IDs, etc. By default, the FormsAuthenticationAction will simply set the Forms Authentication auth cookie.

When the FormsAuthenticationAction sets the auth cookie, it will use the value passed back from the IdP in the <Subject> element to set the username on the cookie. The <Subject> will be in the format specified by the service provider config in <nameIdFormats> (As long as the IdP supports it). If the "persistent" NameIDFormat is used, a "Persistent Pseudonym Mapper" can be configured in the <identityProviders> configuration to automatically look up a local username from the returned value, instead of storing that value directly.

Alternatively, custom Actions can be created to replace the FormsAuthenticationAction and perform custom actions in these cases (such as needing to look up local users by additional returned attributes, etc.).