SAML Sample Application

July 10, 2009

SAML Sample Application

The samlinterop sample application demonstrates support for OASIS WSS SAML Token Profile 1.0 in XWS-Security. Security Assertion Markup Language (SAML) assertions are used as security tokens. SAML provides a means by which security assertions about messages can be exchanged between communicating service endpoints. SAML is also considered important for promoting interoperable Single-Sign-On (SSO) and Federated Identity. This release, JWSDP 1.6, adds partial support for SAML Token Profile 1.0.

This sample application was used as Sun’s entry in a virtual interoperability demonstration sponsored by OASIS. This sample implements three out of the four interop scenarios required by the event and described in the WSS SAML Interop Scenarios document. The scenarios addressed in this interop are described in SAML Interop Scenarios. Read more about the SAML interop scenarios at the following URL:

The application prints out both the client and server request and response SOAP messages. The output from the server may be viewed in the appropriate container’s log file. The output from the client is sent tostdout or whichever stream is used by the configured log handler. Messages are logged at the INFO level.

In this example, server-side code is found in the /swainterop/server/src/swainterop/ directory. Client-side code is found in the /swainterop/client/src/swainterop/ directory. The asant (or ant) targets build objects under the /build/server/ and /build/client/ directories.

SAML Interop Scenarios

All four SAML interop scenarios invoke the same, simple application. The Requester sends a Ping element with a value of a string. The value of the string should be the name of the organization that has developed the software and the number of the scenario, e.g. “Sun Microsystems – Scenario #1”. The Responder returns a PingResponse element with a value of the same string. These scenarios use the Request/Response Message Exchange Pattern (MEP) with no intermediaries. All scenarios use SAML v1.1 Assertions.

To validate and process an assertion, the receiver needs to establish the relationship between the subject of each SAML subject statement and the entity providing the evidence to satisfy the confirmation method defined for the statements. The two methods for establishing this correspondence are Holder-of-Key (HOV) and Sender-Vouches (SV). For more information on these confirmation methods, read SAML Token Profile 1.0.

The following is a summary of each of the SAML interop scenarios.

  • Scenario #1 – Sender-Vouches: Unsigned
  • The request contains a minimal sender-vouches SAML assertion with no optional elements included. There are no signatures or certificates required. The response does not contain a security header.

    In this scenario, there is no technical basis for trust because the messages are sent in the clear with no content or channel protection. This scenario is intended only to demonstrate message structure interoperability and is not intended for production use.

  • Scenario #2 – Sender-Vouches: Unsigned: SSL (sample not provided)
  • The request contains a sender-vouches SAML assertion. There are no signatures required. This scenario is tested over SSL, and certificates are required to support SSL at the transport layer. The response does not contain a security header.

    In this scenario, the basis of trust is the Requester’s client certificate used to establish the SSL link. The Responder relies on the Requester who vouches for the contents of the User message and the SAML Assertion.

    This scenario is not demonstrated in this sample application.

  • Scenario #3 – Sender-Vouches: Signed
  • The request contains a sender-vouches SAML assertion. The Assertion and the Body elements are signed. A reference to the certificate used to verify the signature is provided in the header. The response does not contain a security header.

    In this scenario, the basis of trust is the Requester’s certificate. The Requester’s private key is used to sign both the SAML Assertion and the message Body. The Responder relies on the Requester, who vouches for the contents of the User message and the SAML Assertion.

  • Scenario #4 – Holder-of-Key
  • The request contains a holder-of-key SAML assertion. The assertion is signed by the assertion issuer with an enveloped signature. The certificate used to verify the issuer signature is contained within the assertion signature. The message body is signed by the Requester. The certificate used to verify the Requester’s signature is contained in the assertion SubjectConfirmation. The response does not contain a security header.

    In this scenario, the basis of trust is the Assertion Issuer’s certificate. The Assertion Issuer’s private key is used to sign the SAML Assertion for the User. The Responder relies on the Assertion Issuer to have issued the assertion to an authorized User.

SAML Interop Sample Configuration Files

The following sections provide the example configuration files for SAML interop scenarios 1, 3, and 4:

Sender-Vouches Sample Configuration Files

The security configuration pair sv-saml-client3.xml and sv-saml-server3.xml enable the following tasks, as required by Scenario #3:

  • Client contains a sender-vouches SAML assertion.
  • Client signs the assertion and the body elements.
  • Client includes a reference to the certificate used to verify the signature in the header.
  • Client sends the request body.
  • Server verifies that a SAML assertion is received.
  • Server verifies the signature.
  • Server sends the response, which does not contain a security header.

The sv-saml-client3.xml file looks like this:

                                                                                                 { envelope/}Body                                                                                                                                                                           sample.SecurityEnvironmentHandler        

The sv-saml-server3.xml file looks like this:

                                                                                {}Body                                                        sample.SecurityEnvironmentHandler        

The other security configuration files in the /samlinterop/config/ directory that contain a sender-vouches type of assertion are those in support of Scenario #1, the sv-saml-client.xml and sv-saml-server.xml pair.

Holder-Of-Key Sample Configuration Files

The security configuration pair hok-saml-client.xml and hok-saml-server.xml enable the following tasks, as required by Scenario #4:

  • Client contains a holder-of-key SAML assertion.
  • Client has the assertion signed by the assertion issuer with an enveloped signature.
  • Client includes the certificate used to verify the issuer signature in the assertion signature.
  • Client signs the request body.
  • Server verifies that a SAML assertion is received.
  • Server verifies the signature.
  • Server sends the response, which does not contain a security header.

The hok-saml-client.xml file looks like this:

                                                                                   { envelope/}Body                                                                      sample.SecurityEnvironmentHandler        

The hok-saml-server.xml file looks like this:

                                                                    {}Body                                               sample.SecurityEnvironmentHandler        

Running the SAML Interop Sample

To run the samlinterop sample application, follow these steps:

  1. Complete the tasks defined in the following sections of this addendum:
  2. Start the selected container and make sure the server is running. To start the Application Server,
    1. From a Unix machine, enter the following command from a terminal window: asadmin start-domain domain1
    2. From a Windows machine, choose StartRight ArrowProgramsRight ArrowSun MicrosystemsRight ArrowJ2EE 1.4Right ArrowStart Default Server.

  3. Modify the file to set up the security configuration that you want to run for the client and/or server. To do this, remove the comment character (#) from beside the client and server configuration pair to be used, and make sure the other security configuration files have the comment character beside them. See SAML Interop Sample Configuration Files for more information on the security configurations options defined for this sample application.
  4. Build and run the application from a terminal window or command prompt.
    • On the Application Server, the command to build and run the application is: asant run-sample
    • On the other containers, the command to build and run the application is: ant run-sample

Note: To run the sample against a remote server containing the deployed endpoint, use the run-remote-sample target in place of the run-sample target. In this situation, make sure that the,endpoint.port, http.proxyHost, http.proxyPort, and service.url properties are set correctly in the file (as discussed in Setting Build Properties) before running the sample.

If the application runs successfully, you will see a message similar to the following:

[echo] Running the client program....      [java] ==== Sending Message Start ====      ...      [java] ==== Sending Message End ====      [java] ==== Received Message Start ====      ...      [java] ==== Received Message End ====      [java] Hello to Duke!   

You can view similar messages in the server logs:

<SJSAS_HOME>/domains/<domain-name>/logs/server.log  <TOMCAT_HOME>/logs/launcher.server.log  <SJSWS_HOME>/<Virtual-Server-Dir>/logs/errors  

How SiteMinder Interacts with LDAP

July 10, 2009

Ever wonder what LDAP calls SiteMinder is really making to your directory? After reading this post you will understand the basics behind View Contents, Authentication and Authorization, and you will be able to mimic these functions using a command line ldapsearch. You will also know about all the connections that SiteMinder holds open to the LDAP and what those connections are used for.

First the basics on ldapsearch:
ldapsearch is always in the format:

The search filter must appear after all of the switches, and is not prefixed by a switch of its own. After that, if you do not want the entire record, you can specify what attribute(s) you do want returned.

The letters in the following pics will be used throughout the doc when illustrating how to mimic SiteMinder functions with a command line ldapsearch.

Fig. 1

Fig. 2

View Contents:
NOTE: Clicking “View Contents” while inside a User Directory is identical to the behavior when you click the “Add/Remove” button while inside a Policy.

This function ONLY uses the Server field and the Root field, it does NOT use the LDAP User DN Lookup fields.
By default, it executes 5 ldap searches against the directory:
This is ONLY to populate the first window that comes up for View Contents. Any other objects can be found using the binoculars, and doing a search.

To mimic “View Contents” with ldapsearch:

ldapsearch -h A -b B -D E -w F (objectclass=organization) dn
ldapsearch -h A -b B -D E -w F (objectclass=organizationalunit) dn

Fig. 3

Quite often, one or more of these searches will return a sizelimit or adminlimit exceeded error. This error is being returned by the ldap, and could be resolved on the ldap side by increasing the limit of objects that are allowed to be returned by the Administrative user that is configured in your User Directory object. The other solution is to stop the policy server from doing a search for that specific objectclass when you click View Contents. In the registry of the policy server, this is found under:


You can safely remove any of the entries from the LDAP entry in this registry key, and then when you click View Contents, you can still find any specific item by using the binoculars.

Fig. 4


Authentication uses all the settings on the Directory Setup tab. It can either be a one or two part process, depending on the presence of parentheses in the Lookup Start and End.

2 step process:
If you DO use parentheses, then SiteMinder does a search first to obtain a list of DN’s that match the search. This is the disambiguation phase of authentication. Any attribute can be used in the search.

Fig. 5

For instance, if in Fig. 5 you use:

Start: (uid=
End: )

Then users will need to enter the value of their uid attribute in order to be found.

If you use:

Start: (mail=
End: )

Then users will need to enter their email address in order to be found.

Whatever the user types in at the prompt will get sandwiched between the lookup start and end when doing the ldapsearch. No matter what attribute you use, Siteminder always ends up with a list of DN’s. If SiteMinder finds 0 objects that match, then authentication fails, an OnAuthAttempt rules will fire if you have any.

To mimic the disambiguation phase of authentication using ldapsearch: (let’s call whatever the user entered at the prompt “userentry”):

ldapsearch -h A -b B -D E -w F CuserentryD dn

Once Siteminder has a DN (or list of DN’s) it is time to attempt a BIND. It takes the first DN, and attempts a BIND with the password entered by the user at the prompt. If that fails, then it tries the next DN.

If all BIND attempts fail, then authentication fails, and OnAuthRejectrules will fire if you have any.

1 step process:
If you DO NOT use parentheses in the lookup start and end, then it is assumed that ALL of the users who will be authenticating have IDENTICAL DN’s, except for whatever will be entered at the prompt. There is no search executed. Whatever the user types at the prompt will be sandwiched in between the lookup start and end, and this will be considered a valid DN to bind to the directory.

Fig. 6

In Fig. 6, if the user enters jdoe when prompted, the dn will be constructed as:


and then the BIND is issued.

If it fails, then authentication fails, and OnAuthReject rules will fire if you have any.

This is a much faster method of authentication, but is rare, as customers VERY rarely have all of their users under one container (ou) in the directory.


The authorization service uses none of the settings on the Directory Setup tab, other than the Server field. Once you are in the authorization process, SiteMinder already knows the user’s DN, so there are no “user lookups” during authorization. The authorization service is responsible for proving whether or not the DN that was handed to it has a “binding” to the object that was put into the policy.

The way that authorization proves or disproves this depends on the objectclass of the object that you add into your Policy object. When you add something, the first thing SiteMinder does is check the objectclass, and you can see it in the window as below.

Fig. 7

This objectclass is then mapped to a “type” using the registry key:


Fig. 8

This “type” tells the authorization service how to accomplish the authorization of the user. The two most common types are type 2 “Group” style authorization, and type 5 “DN” style authorization.

Type 2 means that SiteMinder will do a search through the group object to see if the user is a “member” or “uniquemember” of the group. SiteMinder sends a “true/false” search to the directory, to see if the group has a member who matches the DN of the user who is trying to authorize:

ldapsearch -h -b “cn=managers,ou=groups,dc=cb,dc=com” -D “uid=SMAdminUser,ou=admins,dc=cb,dc=com” -w (uniquemember=uid=jdoe,ou=internal,dc=cb,dc=com)

A group object looks like the following:

dn: cn=managers,ou=groups,dc=cb,dc=com
objectclass: top
objectclass: groupOfUniqueNames
cn: managers
ou: groups
description: All corporate managers
uniqueMember: uid=sso,ou=internal,dc=cb,dc=com
uniqueMember: uid=jdoe,ou=internal,dc=cb,dc=com

NOTE: this is a groupOfUniqueNames, so the members will be called “uniquemember”s. If it was a group, or groupOfNames, the members would likely be listed as “member”s. But the process is the same, and as you can see in fig. 8, they are all type 2.

In this case, the group only has two users in it, uid=sso and uid=jdoe. So if you put the managers group in your policy, either of those 2 users would be able to authorize.

Special case: Active Directory
In Active Directory, when you add a user to a group, it does not just modify the group object to add the user as a member, but it also modifies the user object and lists the group(s) that he is a member of. SiteMinder uses this to its advantage. When dealing with AD, and using a Group in your policy, SiteMinder will query against the user object who is trying to authorize, and look at the “memberof” attributes to see if the user belongs to the group contained in the policy:

ldapsearch -h -b “cn=jdoe,dc=myAD,dc=com” -D “cn=ADAdminUser,ou=admins,dc=myAD,dc=com” -w (memberof=cn=administrators,dc=myAD,dc=com)

Type 5 means that SiteMinder will compare the end of the users DN to whatever is in the policy, working from right to left. When a user is “in” an ou, it means that that ou appears in their DN. This is a very quick process for the authorization service, because no search needs to be sent to the directory. The string comparison is done in the authorization service itself. So, in fig. 7, if you just hadou=users,dc=cb,dc=com in your policy, then the user:

uid=sso,ou=users,dc=cb,dc=com WOULD authorize.


uid=chris,ou=support,ou=users,dc=cb,dc=com WOULD authorize.

But the user:

uid=jdoe,ou=managers,dc=cb,dc=com WOULD NOT authorize.

Type 1 means that you have put an actual “user” into your policy. An object who has objectclass=User, or objectclass=person, or objectclass=orgperson, or objectclass=inetorgperson.
This type of authorization is very similar to TYPE 5, as the processing is done inside the authorization service, and does not go to the directory at all. For TYPE 1, SiteMinder compares the entire DN of the user to the DN that was put into the policy.

Type 3 means that SiteMinder will check the user’s record for a certain attribute/value pair. So in fig. 7, if you just had (l=US) in the policy, then SiteMinder would check the user’s record to see if they have that attribute/value pair. This is another “true/false” search with a base DN that starts at the user’s record, and only matches if the attribute/value pair is present:

ldapsearch -h -b uid=jdoe,ou=users,dc=cb,dc=com -D “uid=SMAdminUser,ou=admins,dc=cb,dc=com” -w (l=US)

TYPE 7 (all):
Type 7 is a special case, and is an undocumented feature. It is not even in the registry, and it simply means that EVERY authenticated user will automatically be authorized. If you would like every user to authorize, as long as they successfully authenticated, then put the word all into the Manual Entry field, and click the Add button.

Siteminder holds 3 connections open to each LDAP user directory. They are as follows:

DIR: This connection is held open by the user who is configured in the “Credentials and Connections” tab of the User Directory. The initial search for users in authentication is done over this connection, and any WRITE operations (due to Password Services) are also done over this connection. There are a lot of questions about what permissions the Admin user needs to have, and it’s simple… if you will not be using Password Services, then the user just needs to have READ permissions to the section of the user directory where your users are (whatever you put in the Root DN of the directory). If you will be using Password Services, then that user needs to at least have the same READ permissions, and also have WRITE permissions to the attributes in the User Attributes tab of the user directory.

USR: This connection is used by authentication to try the BINDs. No other data is sent across this connection. A BIND is attempted and if it works, then the user is authenticated. The connection is left in that state, owned by the user who just bound. When the next authentication attempt is made, the handling depends on the type of directory. If the directory supports REBIND, then that is what is done, meaning the connection is never broken down, it is just overtaken by the new BIND. If the directory does not support REBIND (like AD), then the connection is Unbound and then a BIND is performed with the new user.

PING: This connection is used to monitor the health of the directory. It sends a very basic search to the directory. If it gets a response, then the directory is considered healthy, so the Policy Server will continue to send requests there.
The search has a blank Root DN, a scope of “base”, and looks for objectclass=*. According to LDAP spec (RFC 2251), all compliant LDAPs will return some basic info about itself and its capabilities when a query is received with those parameters:

ldapsearch -h -b “” -s base objectclass=*


PingFederate for SiteMinder

June 7, 2009
Few organizations have six to nine months to deploy secure Internet single sign-on with SiteMinder, and even fewer organizations can afford the implementation costs. Having already spent hundreds of thousands of dollars, and sometimes over a million, organizations are looking for an easier and less expensive way to provide federated identity management with SiteMinder. Organizations are turning to secure Internet single sign-on (SSO) to decrease the time and cost of providing direct access to SiteMinder protected resources and leveraging SiteMinder for identity federation with external service providers.


With PingFederate and PingFederate’s® CA SiteMinder Internet single sign-on (SSO) integration kit, organizations can easily leverage their SiteMinder (formerly Netegrity SiteMinder SSO) authentication capabilities, to provide internal users with direct access to external resources over the Internet. With the same integration kit, organizations can also provide external users, such as partners and suppliers, with secure Internet SSO to resources protected by SiteMinder.

The PingFederate SiteMinder integration kit can be rapidly installed and configured less than a day, giving internal users authenticated by SiteMinder and external users who need to direct access SiteMinder protected resources immediate Internet SSO capabilities. With a PingFederate’s standalone software, you can address all of your SiteMinder secure Internet SSO needs from a single system:

  • As an identity provider (IdP) you can provide your users with SSO to external services over the Internet such as software as a service (SaaS) and business process outsourcing (BPO) where they are automatically authenticated by your SiteMinder server
  • As a service provider you can provide your external partners and managed services Internet SSO to applications protected by SiteMinder
  • You can provide internal SSO for the enterprise and its acquisitions, affiliates, subsidiaries and joint ventures regardless of the version of SiteMinder or identity and access management system (IdM) each organization has deployed.

PingFederate for SiteMinder allows your organization to:

  • Decrease the cost and time of Internet SSO implementation by 90%
  • Improve access by leveraging existing SiteMinder authentication
  • Decrease security risks associated with SSO over the Internet
  • Provide secure Internet SSO for all connections

More Here


SiteMinder AutoLogin Issue

May 16, 2009

Hi everyone.

I’ve been trying to use a SiteMinder based autoLogin, but i can’t manage to set it properly. I hope someone will be able to tell me what i am doing wrong.

Thing is, i don’t want to use the ext environment.

In my, i’ve put :


Then, i have my in a jar placed in tomcat/common/lib

My SiteMinderAutoLogin class extends CASAutoLogin and has a
public String[] login(HttpServletRequest request,
HttpServletResponse response)
throws AutoLoginException

The first statement in the Login method is printing something out, just to see if the method is called.

Problem is, that method is neved called…
What am I doing wrong ? Why is my custom auto login never used ?
Any suggestions ?

More Here


Configuring ADAM as a SiteMinder Policy Store

May 10, 2009

Microsoft’s ADAM directory provides a free, tightly integrated directory for storing SiteMinder policy information. Unfortunately, ADAM’s interface is not all that easy to understand which makes the initial configuration a little more complicated than desired. Additionally, finding all the specifics on what is needed on the SiteMinder side can be a little unnerving. This article breaks down the installation and configuration of ADAM for use as a SiteMinder policy store. So, let’s get started!

1. Download and Install ADAM

This is probably the most obvious step. As of writing this blog article, the latest version of ADAM can be found here:

The download at the link above contains the SP1 integrated package. So, this eliminate the need to install patches after the initial install. After the download completes, run the installer to install the base components.

2. Create a New ADAM Instance

Now that ADAM is installed, you need to create a new instance. To create a new instance select:

Programs -> ADAM -> Create an ADAM Instance

Be sure to create a Unique Instance when creating the new ADAM instance.

Next, give you ADAM instance a name. In this case, I chose to call it “MyADAM”.

On the next screen, be sure to select ports available on the system where you are installing ADAM. The defaults are 50000 (unencrypted) and 50001 (SSL).

Be sure to select “Yes, create an application directory partition” on the next screen. You can name the partition something meaningful for you. I chose “dc=mycompany,dc=com” for my partition name.

You can then change the locations to store the files associated with ADAM. I left mine set at the defaults. If you want to change the account used to run ADAM, you can change that on the next screen. I recommend using the Network service account unless you are a fan of dealing with Windows permissions (which I am not). Select “Current Logged in User” for the account with administrative rights to the ADAM instance.

On the next screen be sure to import the base LDIF files to initialize the ADAM instance. While they may not all be necessary, I select all of them on this screen.

You can then complete the ADAM instance configuration.

3. Administrator Account Access

Start ADAM ADSI Edit under:

Programs -> ADAM -> ADAM ADSI Edit

If your ADAM instance in not configured, select “Connect to…” and put in the port number of your ADAM instance. In my case, I left the default of 50000.

In the console tree, expand Connection Name, where Connection Name is the connection that you used above. Next expand “CN=Configuration,CN={GUID}” where GUID is a unique 128-bit number representing the user. Then expand “CN=Services” and finally expand “CN=Windows NT”.

Right-click “CN=Directory Service”, and select Properties:

In the Attribute list, locate and then click msDS-Other-Settings, and then click Edit.

In the Value to add box, type ADAMAllowADAMSecurityPrincipalsInConfigPartition=1, and then click OK.

Delete the existing value of “ADAMAllowADAMSecurityPrincipalsInConfigPartition=0″ and click OK to close the Directory Service Properties dialog box.

4. Create Administrator Account

The next step will be to create an administrative account for SiteMinder. Right-click on “CN=Roles” and select New -> Object…

On the next screen select “user” as the type of object:

Set the cn value to the name of the administrator and click the Next button. I chose “Administrator” for my users.

Click the “More Attributes” button on the next screen:

Set “displayName” attribute to your user display name, I picked “SiteMinder Admin”. Then set the “msDS-UserAccountDisabled” attribute to FALSE and the “msDS-UserDontExpirePassword” attribute to TRUE.

You may also need to set the “ms-DS-UserPasswordNotRequired” setting to TRUE if you can not save the user due to a password policy.

Next Right-Click on the “CN=Administrators” group and select Properties. Find the “member” attribute and click the Edit button (you may want to copy the distinguishedName of your user before doing this step).

Click the “Add ADAM Account…” button and put in the DN of the user we created above.

The last step is to select the user, right-click and reset the password:

5. Configure SiteMinder Policy Store Settings

After prepping ADAM, you’re finally ready to start on the SiteMinder side of things. The first step is to launch the SiteMinder Policy Server Management Console and select the Data tab. You will need to set the following items:

a. Enter IP and port number of ADAM
b. Enter partition name for root DN “dc=mycompany,dc=com”
c. Paste complete DN of ADAM administrator account you just created into “Admin Username” box

For example, the user we just created has a DN of:


d. Click on Test LDAP Connection to verify connection works.

6. Set Up the Policy Store

After configuring the policy server to talk to ADAM, you will then need to configure the policy store. Open a cmd prompt and run the following commands:

a. C:\> smldapsetup status

b. C:\> smldapsetup ldgen -fadamschema.smdif

c. C:\> smldapsetup ldmod -fadamschema.smdif

d. C:\> smreg -su (NOTE: You may need to copy smreg into the siteminder bin directory to complete this step)

So, for me this looks like:

C:\> smreg -su password

e. C:\> smobjimport -i smpolicy.smdif -dsiteminder -w -v

So, for me this looks like:

C:\> smobjimport -i”C:\Program Files\netegrity\siteminder\db\smdif\smpolicy.smdif” -dsiteminder -wpassword -v

That’s it! You should now be able to start the policy server and log-in to the policy server administration UI.


XHTML: You can use these tags:

More Here


Siteminder custom login page – how to post to FCC

April 15, 2009

With Siteminder, it is possible to use a custom login page for HTML forms authentication (other than the default login.fcc). This custom login page can be a .html file, .asp file, .jsp, file, etc. In order to properly authenticate users, this custom page will need to perform a POST to the .fcc. Here are the basic steps to get this to work:

* In the System tab of the Siteminder admin UI, right-click on Authentication Schemes and select Create Authentication Scheme
* For Authentication Scheme Type, select HTML Form template
* Enter the fully qualified name of the web server hosting your login page
* For Target, enter the relative path to your custom page. By default, this will be set to “/siteminderagent/forms/login.fcc”. As an example, you may want to set it to “/mycustompages/login.asp”
* In your custom login page (“/mycustompages/login.asp”), make sure the form posts to the login.fcc. The example below assumes you are using the default login.fcc located in the forms directory:
o form id=”myform” name=”myform” method=”POST” action=”/siteminderagent/forms/login.fcc
* Also, your custom login page must contain the following parameters (which Siteminder expects to be present on the POST request to the .fcc):
o input type=text name=”USER”>
o type=password name=”PASSWORD”>
o input type=hidden name=target value=””> [note: in this example, we are parsing the target from the query string. you could also hardcode it]
* Assuming your Web Agent has been properly configured, when users now attempt to access Realms protected using this new Authentication Scheme, they will be redirected to your custom login page.
* After entering their credentials and submitting the form, the POST to the FCC will take place which will authenticate the user and redirect them to the original protected target.

More Here


Implementing XML Encryption in Java

March 9, 2009

In the first column of this series, we presented a high-level WSS4J API, which we wish to implement in this series of columns. In the second column, we discussed the various Java components we are going to use in implementing the WSS4J API. The most important component is XML Security Suite for Java (XSS4J) from IBM alphaWorks. The second column also demonstrated how to use XSS4J for XML encryption.

In this column, we will use the XSS4J concepts discussed in the previous column to implement the XML encryption features in our WSS4J API.

Before we start the discussion, we would like to point out a name clash issue. There’s an open source Web Services Security project at (recently moved to Apache’s web site) that shares the same WSS4J name. The WSS4J API we are developing in this series of columns is purely for educational purposes and aims at demonstrating the use of WSS in Java applications. The WSS4J open source project at SourceForge (now at Apache) is an independent project and is not part of our effort.

More Here


SPML Tutorial

March 27, 2008

SPML (Services Provisioning Markup Language) is an Extensible Markup Language (XML)-based language that facilitates the exchange of provisioning information among applications and organizations, corporations, or agencies. Provisioning, according to the technical group providing support for it, is “the automation of all the steps required to manage (setup, amend, and revoke) user or system access entitlements or data relative to electronically published services.”
SPML was first demonstrated publicly in 2003 by a technical working group of the Organization for the Advancement of Structured Information Standards (OASIS). SPML Version 1 is built on the OASIS Directory Services Markup Language (DSML) Version 2, which is an XML representation of the Lightweight Directory Access Protocol (LDAP). SPML is expected to join a family of standards designed to ease the implementation of Web services, and to establish interoperability among provisioning systems that allow organizations to securely create end-user accounts for Web services and applications from a single point in an organization.

A single SPML request message can be used to simultaneously create user accounts in multiple provisioning systems. Deprovisioning, such as when an employee leaves a company, is done by closing access accounts. This eliminates orphaned accounts and prevents ex-employees from gaining access to customer systems.

More information on SPML here

More Here


SAML Tutorial

December 18, 2007

What is SAML

Authenticating web service calls with SAML

PAWN was designed to operate across multiple administrative domains. For example, in our archive testbed, we already have NARA, UMIACS, SDSC, and and handful of other partners. Each partners is accepting data from various outside groups. In this environment, it is not feasible to enforce any type of centralized authentication service. This presents a problem when a NARA partner wants to use a resource at UMIACS. Assuming that UMIACS doesn’t have the ability to directly authenticate against NARA, how does a partner that can authenticate against NARA use UMIACS resources. In our case, the answer is to use SAML assertions.

A SAML assertion is just an XML file that contains information about who issued it, some statements about some (name, access priveleges, etc), and information to entire entegrity of the token and trust of the client. To access a remote resource in our example, an assertion is issued by NARA to the partner upon successful authentication at NARA (kinda kerb ticket like). The partner can then show that assertion along with proof that it’s allowed to use that assertion to the UMIACS resource, and UMIACS will allow access. Of course there are layers of signatures, and key exchanges that go on under the hood to enable this and keep everything secure.

We use the WS-Security standard to enable initial authentication by username / password, and to handle SAML authenticated methods. In addition, we have some libraries to allow the generation and checking of SAML tokens. We’ve chosen to use the SAML 1.1 specification, and the OpenSAML toolkit.

This just covers how we use SAML tokens in the ADAPT project. There is a lot more to the specification than what we use. This includes token request services, and different types of token workflows. This is described at OASIS Security Services (SAML) TC page.

SAML Assertion

So, what is needed to allow SAML tokens, and what do these tokens contain?

A SAML assertion is nothing more than a bunch of statements about the holder of the assertion. In our case, we use an assertion that contains a single statement of type Attribute Statement. This statement includes who a client is, and what role they are to perform in ADAPT.

A SAML assertion contains several parts, first is the assertion envolope that contains all statements and information about lifecycle and assertion integrity.

Assertion Container

Since the assertion is just a container for statements, the only piece of information we really care about is lifetime for an assertion and integrity information. Lifetime is done with a global Conditions statment that contains a start and end date for the validity of this certificate. The container also contains the issuer of the assrtion.

The integrity of an assertion can be checked by looking at the SignatureValue and KeyInfo sections. These contain the digital signature of the assertion and the certificate used to verify that signature. In PAWN, this would be the public key at a producer site, or scheduler. You can use this key to validate the integrity of certificate during transport, if you use the embedded key, you must check the signing path of that cert back to some trusted certificate authority. You will also need to check that the key is one that you expect (ie, not a different one signed by the same CA). In PAWN, we use a simplier system, each service that consumes these assertions will have a local copy of the Authorities certificate that they can validate the certificate against.

Services that will trust a site’s assertions will need to get it’s keys ahead of time. In an archive environment this exchange is feasable since the trust is largely between a central archive and remote sites, not necessarity between each remote site and every other site. There are project such as the Liberty Alliance and Shibboleth that address some of these issues.




The subject contains a NameIdentifier that gives us two pieces of information. First is has a NameQualifier, this is the domain or realm that this use belongs to. Second, it contains the identity of the user. We just use a plain text username here, but it’s possible to embed any other information, ldap DN, xml, etc.

In PAWN, the nameQualifier is used to specify the domain of an individual user. In combination with the issuer, the namequalifier and actual value specify a unique entity.


Second a subject contains confirmation information. In our case, this the assertion uses holder-of-key as a method for clients to prove they are the rightful owner of this certificate. There are additional confirmation methods, some of which are listed on Sun’s xws tutorial Below the confirmation method, is a certificate that will be used for this. Holder-of-key says that a client must prove they are allowed to use this certificate by showing they have a private key corresponding to the certificate. In the case of web services, the private key proof is to sign the entire SOAP message with the private key, then verify that signature against the embedded cert.

Here is a what the subject confirmation part of a subject looks like:



Since the entire SAML token is by the issuer, and this signature can be verified, we can ensure that nobody changed the embedded certificate or other information and can trust what it says.


We use attribute statements in ADAPT to send a list of all privileges a user has for a given package. a privilege in PAWN is divided into two parts, first is the type of privilege, and second is the action on that type. For example. ‘Package Item’ may be the type and ‘Modify’ may be the allowed action. The type is represented by the AttributeName and the action is represented by a list of AttributeValues. There are two special types that do not follow this pattern.

  • package_id – contains the manager id number of the package as it’s AttributeValue.
  • package_structure – contains a record set document as its value.

Since the roles have to cross sites they need to have a common namespace. We’ve started outlining some available roles [[Main.SamlRoles][here]]. Of course a 3rd party is allowed to ignore roles that it doesn’t seem fit. For example, the scheduler may only allow certain issuers to modify resource configuration.

Standard type and action


Special package_id attribute


Entire Assertion

The complete assertion that is used for authentication looks as follows:

<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" AssertionID="fd653abed9ae5bcb59ab3665a149ab9f"
IssueInstant="2005-07-15T16:57:42.047Z" Issuer="" MajorVersion="1" MinorVersion="1">





<ec:InclusiveNamespaces xmlns:ec=""
PrefixList="code ds kind rw saml samlp typens #default">





The workflow for using SAML authentication in PAWN follows:

  1. Any service that will trust a 3rd party Authority will need a copy of it’s certificate
  2. Each site will need to have certificates of any certificate authority used.
  3. A client connects to an Authority and authenticated with local security information (username/password) and supplies a certificate that it will use to prove it’s identity.
  4. The Authority authenticates the client and verifies the supplied certificate against CA certificate.
  5. Authority create assertion with client roles, identity, supplied cert, signed the assertion and returns to client.
  6. (optional) If a client doesn’t trust the transport to the Authority, it can validate the assertion.
  7. A client connects to a 3rd party web service. The SOAP message contains the SAML assertion in the header plus a signature of the soap message. Signature is created with private key corresponding to embedded cert.
  8. The consuming service verifies the message signature was generated with the embedded cert, it also checks the saml signature against the Authorities certificate that is has locally.

You can see the sample SAML application here

Identity Theft Protection & Identity Theft Prevention

December 5, 2007

Identity Theft is the one of the fastest growing white collar crimes of the 21st Century. You can no longer afford to ignore identity theft protection.

It takes the average victim up to a year to realize that their identity has been assumed by another person. Identity theft victims have been known to lose their jobs, be refused loans or even arrested for crimes they didn’t commit.

More Here