Overview:
SiteMinder provides federation capabilities for SAML (and other protocols). SiteMinder’s federation capabilities are accessed through a set of web services installed with the Web Agent Option Pack. The federation web service throws a 500 error instead of automatically redirecting the user for re-authentication like a standard SiteMinder Web Agent when the user has a valid SiteMinder session, but is not authorized to access the configured SAML Service Provider. This can be worked around in a couple of ways, but one way to handle this is to leverage the federation 500 error redirect to automatically redirect the user to a page which logs the user out and then redirects back to the federation URL.
The following is required for this configuration:
- Custom redirect page that takes the federation POST variables and redirects the user back to the sent SPID. This page should be placed on a web server with an installed SiteMinder Web Agent.
- Configure the redirect page as the logoff URI within the agent’s configuration object (ACO).
- Set the custom error page as the Server Error URL in the Additional URL Configuration section on the Advanced tab of the SAML service provider configuration dialog.
Custom Redirect Page:
The custom redirect page can be an ASP, ASP.NET, JSP or any other dynamic page that can take POST parameters, parse them and redirect the user back to a URL. The following ASP code is an example of a page that takes the information from SiteMinder and redirects the user back to the federation URL:
<%
Dim relaystate, spid, fedurl, redirecturl
relaystate=Request.Form("RelayState")
spid=Request.Form("SPID")
fedurl="https://saml.company.com/affwebservices/public/saml2sso"
if relaystate = "" Then
redirecturl=fedurl+"?SPID="+spid
Else
redirecturl=fedurl+"?SPID="+spid+"&RelayState="+Server.URLEncode(relaystate)
End If
%>
<html>
<head>
<title>Redirect Page</title>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
</head>
<body>
<% Response.Redirect(redirecturl) %>
</body>
</html>
To use this code, set the fedurl variable to the base federation URL for the environment. The page should then be dropped on a server with a SiteMinder Web Agent in an unprotected folder. For example in a folder like:
<WWW root>redirectlogoffredirect.asp (is the file was an ASP named logoffredirect.asp)
where <WWW root> is the base document folder for the web server site.
Configure the Page as the LogoffUri Agent Parameter:
Setting the custom redirect page as the logoffUri for SiteMinder ensures that the SiteMinder session is ended so that when the user is redirected page to the federation URL they will then be prompted to log in again. In the example above, the URI for the page is /redirect/logoffredirect.asp. To add this:
- Open the Agent Config Oject (ACO) for the Web Agent installed on the server with the custom redirect page.
- Uncomment the LogoffUri parameter and add the URI (not URL) for the custom redirect page.
- Save the ACO.
The configuration change will be automatically picked up be the agent. In this example, the ACO looks like the following image:
Set the Server Error URL:
Once the custom error page is deployed and configured as the LogoffUri, the next steps is to tell SiteMinder to redirect to this page when the user would normally receive a 500 error from the federation web service. While we are using to redirect the 500 error thrown when a user is not authorized, this has the side effect of sending all 500 errors to the redirect page. This may or may not be an issue in your environment. To configure the Server Error URL:
- Open the SiteMinder FSS Administrative UI.
- Click on the Domains tab.
- Open the federation domain.
- Click on the SAML Service Providers left-nav item.
- Open the Service Provider configuration.
- Click on the Advanced tab.
- Click the [Custom Error URL Config] button.
- Check the Enable Server Error URL checkbox.
- Enter the URL for the custom redirect page (e.g. https://saml.com.com/redirect/logoffredirect.asp).
- Change the drop-down to Http Post.
- Save the configuration.
Setting the drop-down to Http Post is required so that the necessary information is sent to the redirect page. This allows the redirect page to redirect the user back to the correct Service Provider configuration. Making the redirect page dynamic ensures that a common redirect page can be used for multiple Service Provider configurations.
Thanks for the workaround. The only problem i see with this approach is, the user will end up on the Login page after authorization failure without any message that he is not authorized/how to obtain access.
User may not know why he ended up on the login page.
the approach I followed is: Come up with a launch page for each SAML app using ASP/JSP/HTML
This page contains a META-Redirect to each app’s corresponding IDP Init URL.
All these launch pages can be protected with SiteMinder using a regular policy domain, where we can restrict the access based on Groups/Attributes. OnAzReject We can redirect the user to a AzReject page which displays a message to the user on further instructions.
Thanks
Ram
Thanks Ram. The issue with this approach is that for SP-initiated requests where a user already has a session on the IdP, you will not go through the flow of hitting the protected page. So, in that scenario a 500 error will still be thrown. Perhaps a combination of approaches could be leveraged. Additionally, for SP-initiated requests, you would have to have a separate authentication URL to use this method for users that do not have an active IdP session. Having the multiple authentication URL’s would handle the IdP initiated scenario for being able to redirect to a not authorized page as well, though.
Todd
You said, “redirects back to the federation URL.”
I wonder why you want to redirect to federation URL? User is not authorized for SP/IDP Federation then user should be sent back to normal paged where he was initially logged in.
For example, If user is logged in chase and then click on federation url. He gets 500 and redirected back to chase my account where he initially clicked the federation link.
- G
That way they can be rechallenged for authentication similar to the normal agent behavior. The normal agent behavior with SiteMinder when you are not authorized to access a resource, is to redirect to the authentication scheme for the realm associated with the resource. Since you’ve now been logged out, SiteMinder will redirect to the authentication URL instead of just displaying the 500 error. If you have a different requirement, you can definitely use this model as a way to implement that as well. The goal here, though, was to let a user log in again with a different (authorized) ID. Make sense?
Todd
Hi i am using java and integreating siteminder. we have login.html and after entering valid username and password, user will be redirected to after login landing page. however if a user click on browser back button it is taking user to login page and from there if a user click on browser FWD button then it is taking to after loing landing page. could any one help me to how to avoid logged in user acces login page? any setup is there in siteminder for this ?
Are you using this for authentication to federation protected resources?
The page before the landing page is the login page. So, the back button will take you there. This isn’t related to SiteMinder itself.
Yes, i am using it for protected resources. i want to check like if SMSESSION orJSESSION is exist then user should not able to access login.html untill he logged off. is there any way to check this ?
This blog post is for protecting federation resources. If you have unrelated comments/questions, please go here for assistance:
http://www.ssohelp.com
You can check for whatever kind of cookie you want on your login page. Either Javascript or server side code (jsp, etc.) will work.