My online notepad
A year ago I posted an explanation about unauthenticated junctions for WebSEAL. Let’s do the similar task with pdadmin – create a "passthrough" ACL for WebSEAL.
[ Note: This post assumes that you have authenticated ‘pdadmin’ session opened! ]
First, we will create a fresh ACL:
pdadmin sec_master> acl create webseal-passthrough
pdadmin sec_master> acl show webseal-passthrough
ACL name: webseal-passthrough
Description:
Entries:
User sec_master TcmdbsvaBRl
pdadmin sec_master>
This is the first in the series of posts that explain how to complete various tasks with ‘pdadmin’ command line tool. All versions of IBM Security Access Manager for Web (formerly known as IBM Tivoli Access Manager for e-Business) come with this tool, which sometimes makes it much more useful than Web Portal Manager UI. Here I will cover the basics – how to open the pdadmin shell and how to authenticate yourself.
There are several possible ways to get to the pdadmin prompt.
The first thing you have to do after the pdadmin prompt was opened is to authenticate your session to the server. This task is pretty straightforward.
pdadmin> login Enter User ID: sec_master Enter Password: ******** pdadmin sec_master>
Note that there is no need to issue explicit login command when working via HTTP API, since the authentication credentials are specified in the dedicated section of the HTTP payload.
After struggling some time with CAS, I finally ended up working with SimpleSAMLphp package. I can recommend it as really simple yet powerful software. The package contains ready-to-use SAML 2.0 IdP site and provides PHP API to integrate your application with SAML 2.0 Service Provider functionality. The handling of the actual authentication process is delegated to a rich set of authentication modules, and in case no build-in module fits your needs – you have all the power to implement your own module in hours.
Installing Apache HTTPD web server with PHP and OpenSSL support on Windows box is not a trivial task nowadays. First, Apache site does not provide Win32 binaries for the latest HTTPD versions anymore. When you manage to find the place to get the binary itself, you get challenged with additional questions – which binary matches the OpenSSL version of your PHP installation and where to get VC redistributable it requires. This article aims to cover all those topics.
We are going to install Apache HTTPD 2.4.3 with PHP 5.4.11 (latest versions at the moment of writing) on Windows 2003 server.
Apache HTTPD
Fresh Apache HTTPD binaries can be found on Apache Lounge site. Note that you will need the binary compiled with OpenSSL 0.9.8 to work with our future PHP installation. Also, there is a link to VC10 redistributable somewhere at the top part of the download page. Make sure to grab it and install on your Windows box before you start with Apache HTTPD installation and configuration.
Fresh Apache HTTPD distributions come as an archive and not as an installer, but don’t be afraid. Just extract the content of the package and move “Apache24” directory to the “C:” drive. You can start the web server by running “httpd.exe” from “C:\Apache24\bin” folder. In the same folder you can find useful ApacheMonitor utility, which allows you to start and stop the server conveniently. I recommend to create a shortcut to this utility and place it to the startup folder (either yours or for all users). Also, Apache HTTPD can be set up to run as a service on system startup by executing “C:\Apache24\bin\httpd.exe -k install” command.
The minimal web server setup includes changing ServerName in “C:\Apache24\conf\httpd.conf” to be the real FQDN of your server. Now you can start the web service and verify that it is up and running.
PHP
The next step is to get latest PHP binary distribution for Windows from PHP for Windows site. There are “Thread Safe” and “Non Thread Safe” distributions; you will need the Zip archive of the Thread Safe one to run it inside the web server. The site mentions that it requires VC9 runtime, but VC10 you’ve installed for Apache HTTPD is even better. Note that some manuals instruct you to download Apache HTTPD module for PHP support separately, but there is no need for that – it is already included in recent PHP distributions.
Extract the content of the distribution archive to “C:\PHP” folder and copy relevant “php.ini-something” to “php.ini”. Inside “php.ini”, uncomment “extension_dir” configuration option and the line that contains “php_openssl” extension definition. Don’t forget to add “C:\PHP” to your system PATH variable, as some extensions (and OpenSSL among them) rely on it to find additional libraries.
To configure PHP in your web server add the following lines at the bottom of “httpd.conf” file:
# PHP 5 LoadModule php5_module "c:/php/php5apache2_4.dll" AddHandler application/x-httpd-php .php PHPIniDir "C:/php"
In addition, you may want to update “DirectoryIndex” directive to contain “index.php” also.
Now it is the time to restart Apache HTTPD server. Note that you will need to explicitly stop and start the server as two separate operations, as “Restart” button from the Apache Monitor does not reload the system properties. In order to verify your PHP setup, add the following “phpinfo.php” to your web server root:
<?php phpinfo(); ?>
You can verify the parameters of your installation by going to http://localhost/phpinfo.php in the web browser. Don’t forget to remove this file after the test if this is going to be your production setup!
Tip:
On remote server PHP errors will be shown as messages on the server console and not in your RDP window.
[ Update (June 2014): Please take some time to check John’s comment below. ]
Last week I spent some time investigating SAML 2.0 support of Central Authentication Service 3.5.1 (latest version of CAS at the moment of writing). The results were disappointing.
CAS was developed by Yale University in early 2000’s and was donated to open source in 2004. It is primary used in the academic networks, but the use is now extended to the enterprise world. Initial versions of CAS were built around own custom interoperability protocol. Later it was extended to support more protocols – both standard (such as SAML 1.1, OAuth, OpenID) and custom (REST API).
The skeleton for SAML 2.0 support was implemented around 2003. The implementation was driven by the need to integrate CAS with Google Apps for Education even before SAML 2.0 was finalized as a standard in 2005. As you may guess, this implementation is not fully compatible with the approved standard. Unfortunately, it did not change a lot during those ten years. The relevant documentation page says “SAML 2.0”, yet mentions the fact that it is actually intended for Google Accounts in the big red warning at the top. The supporting code is more conscious and presents itself as “GoogleAccountsService”.
But even if you don’t really care about spec compatibility, SAML 2.0 implementation of CAS is extremely limited and is not fully secure.
First, CAS implementation does not support SAML 2.0 metadata. Besides the inconvenience of manual configuration on SP side, it has serious implications on the IdP itself. CAS will not maintain the list of trusted SPs – it will be glad to work with any SP, including malicious ones, and will not verify validity of signed authentication requests. Actually, the whole request content besides the request ID (which must be returned in the resulting assertion) and “AssertionConsumerServiceURL” attibute (see below) is simply ignored.
As another implication of missing metadata notion, CAS will not have the pre-configured return URL for each SP and will rely on “AssertionConsumerServiceURL” request attribute. This attribute is defined as optional in SAML 2.0 specification, and some SP implementations do not provide it. Obviously, CAS will fail (in the ugly way – with NullPointerException) if this attribute is missing and will not be able to continue the flow if it does not contain valid URL. And if all this is not enough, just think about invalidated redirects…
The content of the resulting response is also far from being perfect. It is built from a fixed template, with only few values replaced. Among hard-coded values are assertion issuer (sic!), authentication method and some dates. Even the computed values are mostly not configurable – for example, the assertion is always valid for 1 year. Authentication attributes that are required by some service providers are not supported also.
Bottom line:
If you are looking for enterprise-grade software to be your SAML 2.0 Identity Provider, CAS 3.5.1 is not for you.