A relatively new offering from CA is the SiteMinder Agent for SharePoint 2010. I’ve had the “privilege” of working with this product and while I’m impressed with its integration and what it does, be warned, you will need some patience and to be well versed in working on multiple web platforms.
I say this because the installation and configuration is a mashup of vanilla Apache, TomCat, mutliple different SSL tools, some proprietary CA configurations (that are not yet well documented), and all of the usual SharePoint tools (IIS/PowerShell/Claims Based authentication).
From my own experience with SiteMinder, it is very much a Unix targeted product. As such it is not surprising that it relies on Unix’s web server heavy hitters, Apache and tomcat. Tomcat is capable of running as an independent web server, or can have traffic routed to it from another webserver such as Apache. In the case of the Siteminder Agent, it is doing double duty as it uses both modes.
For this reason, if you are a SharePoint administrator seeking to implement the SiteMinder agent, its time to get very familiar with these technologies as well. Important things to pay attention to if you are a straight IIS admin:
1) Configuration files are case sensitive. If in doubt, copy and paste your paths.
2) Paths may either require forward slashes where backslashes are usually used in Windows, or they may need to be escaped backslashes. This depends on which configuration file you’re editing so pay attention.
3) Get comfortable with a command prompt and Notepad (I highly suggest choosing powershell over the vanilla command prompt for authcomplete goodness)
We decided to implement SSL which doubled our complexity. Additional skill needed here:
1) Familiarty with openssl command line tools. These will handle your certificates for the Siteminder Apache httpd server
2) Familiarity with Java’s keytool. This will handle your certificates for the Tomcat server.
3) Windows certificates, and SharePoint’s Trust store.
4) A good understanding of SSL/TLS, the handshake and client authentication for troubleshooting.
Quick note about #3, any SSL service that SharePoint is going to connect to, must have the destination’s SSL certificate (or it’s CA) added to the SharePoint trust store. It does not use the Windows certificate store to trust remote servers. But, you’ll still need to be comfortable with working with the Window’s certificate store in order to install and grant your IIS apps access to SSL certificates. This is to identify your servers to remote machines. Why they moved the trust store within SharePoint while still requiring knowledge of the Windows Certificate store for its own identification is beyond me.
Quick note about #4, out of the box, one of the services that comes with the Agent for SharePoint requires client SSL authentication. That is, any server (WFE) attempting to connect to the agent must submit it’s own SSL certificate and the agent must trust and handshake with it. You can turn this off on the agent side, but it is an added level of security to prevent unauthorized access to your directory of users.
At the end of the day, the CA SiteMinder Agent for SharePoint 2010 is not a small undertaking, so be sure you are familiar with the tools that will need to be used.
What is the cost involved with ca-sitemeinder for SharePoint 2010 integration ?
Blood sweat an tears, honestly though, I was not involved with the licensing process for this project. Much of our cost was offset by the fact that we already had a pretty extensive SiteMinder footprint for existing non-SharePoint web applications.
If you are starting from scratch or have the option to use another technology (ADFS…) it would probably be much less of a headache. Unfortunately for us, our Unix footprint is larger than our Windows one and our SharePoint site needed to integrate and offer single sign on with the existing sites.
Hi Dude, Thanks for sharing your experience on Siteminder Plugin for Sharepoint 2010, I am starting a project from scratch were the front end is windows servers, will the Siteminder plugin installs Apache (inbuilt) as part of the installation in windows box ?
Cheers,
Aloy
Yes the siteminder installer will setup both Apache and tomcat as well as add then to the windows services. The main thing is getting all of the config files straight, and, if you’re implementing ssl, working with both java keystores and cert/key files
Dear Friend, We are working on a project that requires SharePoint 2010 integration with Siteminder. From your post i understand the configuration challenges. Apart from the configuration Is there any programming effort in sharepoint to work with Siteminder? How the user profile information can be captured?
I came to know that the Siteminder does not provider option for Profile Import. How we can capture the incoming users profile information like Name, Email Id, Country, etc. It would be very helpful if you share some code snippets if you have any.
Thank you.
While we are using the SiteMinder agent to protect a custom developed site, just getting the product up and running will not require any extra coding. Unfortunately, I’ve traded in my developer cap for an administrative one and I’m not familiar with retrieving the user properties from the agent.
I can only make assumptions based on what I do know that may hopefully lead you down the right path. The agent acts as a trusted identity provider for claims based SharePoint authentication.
Underneath the hood, claims based authentication uses SAML, and SAML 2.0 supports attribute queries. I believe this is how you can run an import from ADFS Claims authentication with SharePoint 2010. The user profile service is set up with a connection to the ADFS server and some magic is done with the user profile property mappings back to the claims attributes.
When installing the Agent, you do configure attributes that are pushed to the SiteMinder federation configuration. These attributes are queryable from the people picker, and do come across in the initial SAML token when logging in.
That said, you may be able to retrieve the information you’re looking for out of the authentication token (Microsoft.SharePoint.Administration.Claims might be a good place to start), or if SiteMinder has a full SAML 2.0 implementation by crafting a custom request back to the Agent Server’s web services.
Could you provide “subject alternative name” used for CSR. Since, we are not looking to use wildcard name in the cert ..wondering what are the acceptable names that SiteMinder could consume in the cert that SharePoint is providing.
Sorry for taking so long to respond. I’m not sure if I understand your question. In our case, we took CSRs for individual subjects and when having them signed we requested the extended SAN info be added. We did not use SANs on this project for the SharePoint server itself, each url had its own cert and served data over nonstandard ports to get around the IIS 7.0 binding issue. Luckily the SiteMinder reverse proxy functionality can mask these nonstandard ports for us.
That said, the SiteMinder agent should be able to consume any valid certificate. It relies on the OS’s trusted CA’s for its reverse proxy connections to SharePoint where it is acting as a client request to SharePoint. When serving up data itself, it’ll use the private key/certificates configured in the httpd_ssl.conf. As for the ClaimsWS (web service) used by people picker, that is contained completely within Tomcat and will rely on the JCEKS encoded Java Keystore files (one private keystore for serving, one truststore for client authentication) documented in the install guide.
I am currently working through the “fun” of getting this setup. With the recent release of SharePoint 2013 have you heard of any planned support for the SiteMinder Agent for SharePoint on that version? Thanks.
I haven’t heard any news from CA regarding the Siteminder Agent for SharePoint for 2013. My teammates went to the conference in Vegas and it sounds like the 2010 agents may not be supported.
We are still ironing out some kinks in our own implementation where the product is not fully adhering to the requirements for a trusted identity provider (awaiting CA patches).
So I was privy to a roadmap from CA for their Siteminder Agent for SharePoint and a 2013 version should be coming out soon. (Read: We’re past the date I saw on the roadmap :P)
One good thing to note is that SharePoint 2013 is offloading their claims cache to the AppFabric layer so you can have true load balancing and HA now, instead of a user needing to be sent to the same WFE for every request. (For those of you using load balancers)