Custom
Sample SSO using a .NET custom HTTP module
The advantage of the custom HTTP module solution is that it secures all WorkflowGen HTTP requests, including web services. It also provides more customization possibilities than the form authentication-based solution.
This section focuses on the custom HTTP module authentication solution.
This sample illustrates a very basic scenario that uses a separate IIS website as the remote authentication service provider to host a login.aspx
page (e.g. to simulate an authentication service provider that validates user credentials against an identity provider) and WorkflowGen in another IIS website where the custom HTTP module is installed and configured.
We recommend securing the WorkflowGen website with SSL and using encryption to secure the token. The code provided below is a basic sample, so you might have to customize it to enforce security and hide detailed error messages.
WorkflowGen custom HTTP module authentication configuration
Download the
CustomAuthModuleSSO 2.0
sample package, unzip the package, then copy the\VS Project\bin\Release\CustomAuthModuleSSO.dll
file into the following folders:\wfgen\bin
\wfgen\wfapps\webforms\bin
All of your custom web forms'
\bin
folders
In IIS, change the Authentication configuration. Enable
Anonymous Authentication
on all of the following IIS applications under the WorkflowGen website:\wfgen
\wfgen\wfapps\webforms
All of your custom web form folders
✏️ Note: All of your web service apps (subfolders in the
\wfgen\wfapps\webservices
folder) should be usingBasic
authentication, since this sample redirects to the remote authentication server'slogin.aspx
page, which is not supported in the web service scenario.Edit your
\wfgen\web.config
file and add the following configuration:✏️ Note: Change the
{remoteauthserver:port}
value of the RemoteAuthenticationServiceProviderLoginUrl key to your existing remote authentication server name and port number.If you want to customize the behavior of CustomAuthModuleSSO, open the
\VS Project\CustomAuthModuleSSO.sln
solution in Visual Studio, then edit theCustomAuthModuleSSO.cs
file. When ready, rebuild the solution and redeploy the\VS Project\bin\Release\CustomAuthModuleSSO.dll
file as in step 1.
Remote Authentication Service Provider web server configuration
Copy the
\Remote auth service provider\login.aspx
sample file from the package to your remote authentication server IIS website's root folder. If there's no existing website, then create a new IIS website on your web server and copy the file to the root folder. Normally, the remote authentication server IIS website is a separate website from the WorkflowGen IIS website. ✏️ Note: Don't forget to update the{remoteauthserver:port}
value for the RemoteAuthenticationServiceProviderLoginUrl key in the\wfgen\web.config
file if the remote authentication server name and port are different or have changed. See step 3 of the previous section.Edit
login.aspx
and change the{workflowgenserver:port}
to your WorkflowGen server name and port number.In IIS, change the Authentication configuration. Enable
Anonymous Authentication
on the remote authentication server IIS website.Open the
http://{remoteauthserver:port}/login.aspx
URL in a browser and make sure it's accessible and working properly.
How the sample works
When a user connects to WorkflowGen (
http://{workflowgenserver:port}/wfgen
), CustomAuthModuleSSO checks if atoken
is available (in theCookies
,QueryString
,Form
, orServer variables
collections) in order to retrieve the current login user. If no token is found, then it will redirect the user to your remote authentication serverlogin.aspx
page with a return URL.Your remote authentication server will show a login page for the user to input their username and password for submission.
When the user submits the form, the login page validates the user credentials against the authentication service provider (code to implement in
login.aspx
). If the credentials are valid, then the page generates a token and sets it as a parameter in the WorkflowGen return URL. For the simplicity of this sample, the token only contains the username that is encoded in base64.When WorkflowGen receives the new HTTP request from your remote authentication server, CustomAuthModuleSSO will retrieve the
token
from theQueryString
. It decodes the token to retrieve the username and creates a GenericPrincipal object used to set the current user session, then it saves thetoken
as a cookie for future HTTP requests. WorkflowGen will now use the user principal (GenericPrincipal object) of the HTTP request context to verify and load the WorkflowGen user's profile. If the user is invalid (e.g. no matching username is found in the database), WorkflowGen will reject the user and display aSecurity error: You are not authorized to view this page
error message.For sign out, the user can use one of the following URLs. WorkflowGen will clear the token cookie, which will force the user to log in if they want to access WorkflowGen again.
For a more secure token, the remote authentication server (login.aspx
in this sample) can generate a JSON Web Token containing the user information and sign it using a shared secret key. WorkflowGen must know the shared secret key in order to verify and retrieve the user information from the JWT. There are many JWT signing and verification libraries available on jwt.io.
CustomAuthModuleSSO.cs
source code
CustomAuthModuleSSO.cs
source code login.aspx
source code
login.aspx
source codeGeneric sample code for an HTTP module
Overview
This sample is an HTTP module that uses the HTTP_AUTHORIZATION server variable for authentication. You must insert your own method to authenticate users.
This sample uses the common Basic authentication method to request and retrieve the user credentials. It can be easily modified to use any other standard or custom methods, such as a token
or a username
stored in a cookie, a query string parameter, a form data parameter, or a server variable.
The main objective of this custom HTTP module is to create and set the GenericPrincipal object with a valid login username (in clear text) of the current HTTP request context that will be later used by WorkflowGen to verify and load the user's profile.