OpenAM and ADFS2 configurationGeneralThis document describes how to configure OpenAM as a ‘Service Provider’ and Microsoft Active Directory Federation Server (ADFS) as an ‘Identity Provider’. This document was written based on the experience in a proof of concept.

Use CaseThis document describes the following use case.

There are two network domains;Network A (aaa.local) is the domain with the Service Provider (OpenAM).Network B (bbb.local) is the Microsoft Active Directory Domain and holds the Identity Provider.

Client computer is a Windows XP machine and is a member of the Network B domain controller.A user who is logged on to the Windows XP machine must be able to launch the OpenAM user Profile Page without resubmitting his user credentials.

To achieve the use case scenario, Federation will be used.

The UML diagram below describes the flow of the federated authentication process.

 

Figure 1: UML diagram Federation Process

Explanation of above UML diagram

Step 1: User tries to access a resource on the SP (OpenAM server). This webpage will try to detect if the user has already got an OpenAM session, if not the user will be redirected to the IDP (ADFS) server.A SAML Authentication Request message is generated and sent along with the redirection (Step 2 and 3)In Step 3 the IDP server receives the request. If the client browser has already has an ADFS session, step 4 and 5 are omitted, otherwise an HTTP 401 will be issued to the client which is basically an HTTP authentication request.Step 5 will return the authentication response. In case of NTLM/Kerberos this is an automated process via the SPNEGO protocol.Step 6: the IDP server receives the authentication response and when successful it will generate a SAML response.Step 7: Client browser is redirected back to the OpenAM server where is decodes the SAML response and issues an OpenAM token.

Prerequisites

This section describes the prerequisites for implementing OpenAM and ADFS to support the use case described earlier.

One important requirement for the solution is that both environments need to be SSL configured. For the proof of concept the web sites were configured with self signed certificates to support this. 

ADFS Requirements

For this proof of concept the following software was used to setup the server with ADFS:

Windows Server 2008 R2, Enterprise Edition SP2Internet Information Services (IIS)Microsoft .NET Framework 3.5Active Directory Federation Service 2.0

The installation of Microsoft Active Directory Federation Service is out of scope for this document. 

OpenAM Requirements

For this proof of concept the following software was used.

Windows Server 2003 R2

Tomcat 6Java JDK 6Tomcat configured with SSL.OpenAM 9.5.3OpenDJ 2.4.2

 The installation of Tomcat with SSL is out of scope for this document but it is very important that Tomcat is properly configured with SSL. 

Implementation Steps

The following sections describe the steps to undertake to implement SSO Federation between OpenAM and Microsoft Active Directory.

Please note that if you want to familiarise yourself with Microsoft Active Directory Federation Server, there are Step-By-Step guides available at http://technet.microsoft.com/en-us/library/adfs2-step-by-step-guides(WS.10).aspx

Setting up the OpenAM Service Provider

Install OpenAM

For this Use Case scenario OpenAM 9.5.3 is used together with OpenDJ 2.4.2 as its user data store.

I am not going into great detail on the installation of OpenDJ and OpenAM as we are more interested in the Federation configuration settings.

As the proof of concept is focussing on the Federation configuration settings a default OpenDJ and OpenAM installation is performed. Make sure that OpenAM is accessible on a SSL website. This means that you have to setup Tomcat with a SSL certificate.

Also make sure that OpenDJ is used as User Data Store.

After the installation you should be able to access the OpenAM via

https://sso01.aaa.local:8443/openam

Finally unzip the downloaded ssoAdminTools.zip file and install the Admin tools. This will install the ssoadm.exe tool which can be used to import/export federation provider configuration files.

Setting up a test user

Login to the OpenAM application using the amadmin user and go to Access Control, click on the ‘Top Level realm’ and https://sso01.aaa.local:8443/openamclick on Subjects to create a new user.

This user should also exist in the Active Directory on the IDP01.bbb.local server

Exchange Certificates

If there is a requirement that all data between the Identity Provider and Service Provider is signed and encrypted, then you need to generate certificates for signing and encryption.

On the idp01.bbb.local server these certificates are automatically generated by the ADFS 2.0 installation process.

On the OpenAM server you need to create them manually. Again, to generate certificates you can use the Java keytool.exe tool but KeyStore Explorer is more convenient.

OpenAM uses its own keystore file. In our test environment the OpenAM configuration files are stored in the directory d:\appserv\opensso\. This folder was configured during the installation of OpenAM.

In the folder d:\appserv\opensso\opensso you will find the default keystore.jks file. You can either create a whole new keystore or use this one.

The default password is ‘changeit’.

Use the Keystore Explorer to open the OpenAM keystore.Click on Tools | Generate new Keypair, to generate a new certificate.

Use the details from the below table to create a Token Signing Certificate and a Token Encryption Certificate.

Name Value

Algorithm (RSA or DSA)

RSA

Key size 2048

Signature Algorithm SHA.1 with RSA

Name CN=sso_ts,OU=aaa,O=local

Alias SSO_TS

Password changeit

Name Value

Algorithm (RSA or DSA)

RSA

Key size 2048

Signature Algorithm SHA.1 with RSA

Name CN=sso_te,OU=aaa,O=local

Alias SSO_TE

Password changeit

  

After the certificate is created export the certificate in order to import the public key on the IDP01 server. To export the certificate, double-click on the certificate and click on PEM, then click Export. Save the certificates to D:\sso_ts.cer and D:\sso_te.cer

Also make sure that the Tomcat SSL certificate needs to be exported into a cer file.

To do this you can also use the KeyTool Explorer and export the public key into sso01.cer

On the IDP01.bbb.local server import the public key certificates (sso01.cer, sso_ts and sso_te). To do this, copy the .cer files onto the IDP01 server and start the Microsoft Management Console (MMC.EXE)

Via File | Add/Remove SnapIn | Add, find the Certificates snapin and click on Add.

 Then for each .cer file right click on Personal/certificates | Import and select the .cer files.

This will import the certificates in the Personal store.

Please note that because these certificates are all Self Signed certificates these will not be Trusted. On a production environment you will need to have certificates which have been signed by a trusted CA (Certificate Authority) but for a proof of concept you can use a workaround by adding the certificates to the ‘Trusted Root Certification Authorities’. This can be done similarly as importing into the personal store. Right click on ‘Trusted Root Certification Authorities / Certificates’ and click Import to import each .cer file.

Now you also need to export the Microsoft ADFS server certificates and Import them onto the OpenAM server.

To export the ADFS certificates launch the ADFS 2.0 Management Tool:

In the ADFS2.0 | Service | Certificates screen you will find all the required certificates in one place.

For each of the three certificates, double click to open the Certificates window.

Click on the Details tab and then click on the Copy to File button. This will start the export wizard.

Click ‘No do not export private key’ and select the ‘DER Encoded X.509 (.cer)’ encoding.

Save the files as

IDP01.cerIDP01_TE.cerIDP01_TS.cer

Copy these .cer files over to the OpenAM server.

To import the files on the OpenAM server you can use the KeyStore Explorer tool. Please note that the files need to be imported in both OpenAM keystore and the Tomcat Keystore.

Also because these certificates are self-signed they have to be imported in the CACerts keystore of the Java JRE/JDK being used. Normally the CACerts store can be found in

C:\Program Files\Java\jre6\lib\security\CACerts

Setting up a Circle of Trust

A Circle of Trust defines a set of service and identity providers which trust each other. To begin you first start with creating a hosted service provider in OpenAM.

There are multiple ways to do this, for example on the home page in OpenAM there are options to create hosted and remote Service and Identity Providers, but this option will create basic providers and there is a need to amend the provider settings slightly, so the preferred method is to generate template files, alter the template files and then import them.

The way to generate the template files is to use the ssoadm.exe tool.

To generate the OpenAM Service Provider XML files:

ssoadm create-metadata-templ -u amadmin -f password -m sp.xml -x sp-extend.xml -s /sp –a sso_ts –r sso_te -y https://sso01.aaa.local:8443/opensso -c saml2

To generate the ADFS Identity Provider XML files:

ssoadm create-metadata-templ -u amadmin -f password -m idp.xml -x idp-extend.xml -i /adfs -y https://idp01.bbb.local/adfs/services/trust -c saml2

Next thing is to generate a template with the Microsoft ADFS server details. Microsoft ADFS offers a capability to generate such provider XML files by accessing a webpage.

However this format is not fully compatible with OpenAM and it does not generate the extended metadata file. Therefore the previous creation of the template files was still necessary.

Nevertheless generating the ADFS metadata will give it a correct IDP.XML and you only have to alter the IDP-extended.xml.

First generate the ADFS output by navigating to https://idp01.bbb.local/federationmetadata/2007-06/Federationmetadata.xml

https://idp01.bbb.local/federationmetadata/2007-06/Federationmetadata.xml

and save it to idp.xml

Then open the XML file and remove the following sections entirely:

Ds:Signature RoleDescription SPSSODescriptor

This will only leave the IDPSSODescriptor.

Then amend the IDP-extend.xml. The changed entries are highlighted below in red

<EntityConfig xmlns="urn:sun:fm:SAML:2.0:entityconfig"

    xmlns:fm="urn:sun:fm:SAML:2.0:entityconfig"  entityID="https://idp01.bbb.local/adfs/services/trust">hosted="false"

    <IDPSSOConfig metaAlias="/adfs">

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value>idp01_ts</Value>

        </Attribute>

        <Attribute>

            <Value>idp01_te</Value>

        </Attribute>

        <Attribute>

            <Value>false</Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value>false</Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value>600</Value>

        </Attribute>

        <Attribute>

            <Value>com.sun.identity.saml2.plugins.DefaultIDPAuthnContextMapper</Value>

        </Attribute>

        <Attribute>

            <Value>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|0||default</Value>

        </Attribute>

        <Attribute>

            <Value>com.sun.identity.saml2.plugins.DefaultIDPAccountMapper</Value>

        </Attribute>

        <Attribute>

            <Value>com.sun.identity.saml2.plugins.DefaultIDPAttributeMapper</Value>

        </Attribute>

        <Attribute>

            <Value>com.sun.identity.saml2.plugins.DefaultAssertionIDRequestMapper</Value>

        </Attribute>

        <Attribute>

           <Value>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress=mail</Value>

           <Value>urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName=</Value>

           <Value>urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName=</Value>

           <Value>urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos=</Value>

           <Value>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=</Value>

        </Attribute>

        <Attribute>

            <Value>com.sun.identity.saml2.plugins.DefaultIDPECPSessionMapper</Value>

        </Attribute>

        <Attribute>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

        <Attribute>

            <Value>mycot</Value>

        </Attribute>

        <Attribute>

            <Value>false</Value>

        </Attribute>

        <Attribute>

            <Value>false</Value>

        </Attribute>

        <Attribute>

            <Value>600</Value>

        </Attribute>

        <Attribute>

        </Attribute>

        <Attribute>

            <Value> </Value>https://sso.aaa.local:8443/opensso/idpsaehandler/metaAlias/adfs

        </Attribute>

        <Attribute>

            <Value></Value>

        </Attribute>

       <Attribute>

           <Value></Value>

       </Attribute>

       <Attribute>

           <Value>false</Value>

       </Attribute>

        <Attribute>

        </Attribute>

    </IDPSSOConfig>

</EntityConfig> 

Amend the SP.XML file. The changed entries are highlighter below in red.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>

<EntityDescriptor entityID="https://sso.aaa.local:8443/opensso"

xmlns="urn:oasis:names:tc:SAML:2.0:metadata">

  <SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="true"

  protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"

    Location="https://sso.aaa.local:8443/opensso/SPSloRedirect/metaAlias/sp"

    ResponseLocation="https://sso.aaa.local:8443/opensso/SPSloRedirect/metaAlias/sp" />

    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

    Location="https://sso.aaa.local:8443/opensso/SPSloPOST/metaAlias/sp"

    ResponseLocation="https://sso.aaa.local:8443/opensso/SPSloPOST/metaAlias/sp" />

    <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"

    Location="https://sso.aaa.local:8443/opensso/SPSloSoap/metaAlias/sp" />

    <ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"

    Location="https://sso.aaa.local:8443/opensso/SPMniRedirect/metaAlias/sp"

    ResponseLocation="https://sso.aaa.local:8443/opensso/SPMniRedirect/metaAlias/sp" />

    <ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

    Location="https://sso.aaa.local:8443/opensso/SPMniPOST/metaAlias/sp"

    ResponseLocation="https://sso.aaa.local:8443/opensso/SPMniPOST/metaAlias/sp" />

    <ManageNameIDService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"

    Location="https://sso.aaa.local:8443/opensso/SPMniSoap/metaAlias/sp"

    ResponseLocation="https://sso.aaa.local:8443/opensso/SPMniSoap/metaAlias/sp" />

    <NameIDFormat>

    urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>

    <NameIDFormat>

    urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>

    <NameIDFormat>

    urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat>

    <NameIDFormat>

    urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>

    <NameIDFormat>

    urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName</NameIDFormat>

    <NameIDFormat>

    urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos</NameIDFormat>

    <NameIDFormat>

    urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName</NameIDFormat>

    <AssertionConsumerService index="0"

    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"

    Location="https://sso.aaa.local:8443/opensso/Consumer/metaAlias/sp" />

    <AssertionConsumerService index="1" isDefault="true"

    Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

    Location="https://sso.aaa.local:8443/opensso/Consumer/metaAlias/sp" />

    <AssertionConsumerService index="2"

    Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS"

    Location="https://sso.aaa.local:8443/opensso/Consumer/ECP/metaAlias/sp" />

  </SPSSODescriptor>

</EntityDescriptor>

Amend the SP-extended.XML file. The changed entries are highlighted below in red:

<EntityConfig xmlns="urn:sun:fm:SAML:2.0:entityconfig"

xmlns:fm="urn:sun:fm:SAML:2.0:entityconfig" hosted="1"

entityID="https://sso.aaa.local:8443/opensso">

  <SPSSOConfig metaAlias="/sp">

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value>sso_ts</Value>

    </Attribute>

    <Attribute>

      <Value>sso_te</Value>

    </Attribute>

    <Attribute>

      <Value>false</Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value>true</Value>

    </Attribute>

    <Attribute>

      <Value>uid</Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value>

      com.sun.identity.saml2.plugins.DefaultSPAccountMapper</Value>

    </Attribute>

    <Attribute>

      <Value>true</Value>

    </Attribute>

    <Attribute>

      <Value>

      com.sun.identity.saml2.plugins.DefaultSPAttributeMapper</Value>

    </Attribute>

    <Attribute>

      <Value>

      com.sun.identity.saml2.plugins.DefaultSPAuthnContextMapper</Value>

    </Attribute>

    <Attribute>

      <Value>

      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport|0|default</Value>

    </Attribute>

    <Attribute>

      <Value>exact</Value>

    </Attribute>

    <Attribute>

      <Value>UPN=uid</Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value>300</Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value>URI</Value>

    </Attribute>

    <Attribute>

       <Value>mycot</Value>

    </Attribute>

    <Attribute></Attribute>

    <Attribute>

      <Value>

      </Value>https://sso.aaa.local:8443/opensso/spsaehandler/metaAlias/sp

    </Attribute>

    <Attribute></Attribute>

    <Attribute>

      <Value>com.sun.identity.saml2.plugins.ECPIDPFinder</Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value>false</Value>

    </Attribute>

    <Attribute>

      <Value></Value>

    </Attribute>

    <Attribute>

      <Value>0</Value>

    </Attribute>

    <Attribute>

      <Value>false</Value>

    </Attribute>

    <Attribute>

      <Value>false</Value>

    </Attribute>

    <Attribute></Attribute>

  </SPSSOConfig>

</EntityConfig>

Finally import the provider XML files.

Navigate to and logon using the amadmin account.https://sso01.aaa.local:8443/openam

Go to the Federation Tab.

First create a new Circle of Trust (1) and name it mycot. Secondly import the identity providers. This can be done by uploading the metadata XML files. You need to upload both the metadata and the extended metadata files per provider.

Notice that some settings in the metadata XML files are not imported correctly.

Please verify and alter the following settings.

Go to the Service Provider ( ). On the Assertion Content Tab, check the following Signing and Encryption tick boxes and https://sso01.aaa.local:8443/openamtick them accordingly.

Also make sure that the nameIDMapping in the Identity provider settings is set.

Click on the Identity Provider settings, go to the Services Tab and verify that the NameIDMapping in the bottom of the screen is set to upn=uid.

Configuring the Active Directory Federation Server

By default Microsoft 2008 enterprise server does not supply the ADFS 2.0 component. Instead the 1.0 version is available for install. It is better not to install the 1.0 version but to download the 2.0 version and then perform the installation.

The installation of ADFS 2.0 automatically generates the necessary certificates for the default website but also for the Token Signing and Token Encryption. Please note that these certificates are self signed certificates and therefore not trusted by others.

In order to configure the Circle of Trust in ADFS you need to add a Relying Party Trust (OpenAM server) via the ADFS 2.0 Management tool:

  

There a 3 ways to creating a Relying Party Trust. One of them is importing the metadata XML files just like you have done for OpenAM. However ADFS lets us use the OpenAM federation URL to obtain the metadata dynamically. So selecting the first option and use the following URL

https://sso01.aaa.local:8443/opensso/saml2/jsp/exportmetadata.jsp

https://sso01.aaa.local:8443/opensso/saml2/jsp/exportmetadata.jsp

This will import the Relying Party Trust.

After importing the metadata please review the following properties

On the Encryption Tab, please verify that the sso_te Certificate is selected.On the Signature Tab, please verify that the sso_ts Certificate is selected.On the Advanced Tab, please make sure that the SHA1 algorithm is selected.

After creating the Relying Party Trust you also need to define the claim rules to define what information you are allowing to be sent over to this trusted provider. In our proof of concept I used the Windows Account Name to be sent over to OpenAM. In order to do this you need to create two Claim rules in the Edit Claim Rules wizard.

First you need to create a generic LDAP rule where you have to map the internal Active Directory LDAP attributes to Claim Types.

In our case I mapped the SAMAccountName to the outgoing claim type UPN:

The second rule is very custom. Although ADFS allows you to create Claim Rules via a Wizard and also create ‘Transform Claim Rules’ where you can easily transform incoming claims and assign different attributes into it, it does not work for OpenAM. Mainly because ADFS expects a ‘spname’ qualifier to be present in the request which OpenAM is not sending. Therefore you need to create a custom rule. ADFS 2.0 provides the option to define custom rules that can be used to determine the behaviour of identity claims with the claim rule language.

Please note that the spnamequalifier is added in the Claim request.

  

 c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]

 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",

          Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer,

               Value = c.Value, ValueType = c.ValueType,

               Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"]

                    = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient",

               Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"]

                    = "http://idp01.bbb.local/adfs/services/trust",

               Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/ "]spnamequalifier

                    = );https://sso01.aaa.local:8443/opensso

Configuring the ClientOn the client machine you need to configure the user’s Internet Explorer settings so the browser trusts the OpenAM federation server. This is done by adding the sso01.aaa.local federation server into the Local Internet sites

To configure the browser settings to trust the sso01.aaa.local federation server

Start the internet explorerOn the Tools menu, click Internet optionsOn the security tab, client the Local Internet icon, and then click sitesClick Advanced, and the URL https://sso01.aaa.local

Test the Single Sign onBefore testing the Single Sign On you need to make sure that the testing user does exist in both ADFS and OpenAM user stores.

There are two ways of testing the functionality: Either by accessing the OpenAM service provider or by first going to the ADFS IDP.

If you go to the OpenAM service provider directly, OpenAM will check if you have been authenticated to OpenAM already and if not it will redirect you back to the ADFS IDP. On the IDP you need to authenticate to ADFS. For the moment it is not using IWA (Integrated Windows Authentication via NTLM or Kerberos) yet. After logon you will be redirected back to OpenAM where federation takes place and your local OpenAM session will be created.

Via HTTP-Post method

[https://sso.aaa.local:8443/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&NameIDFormat=transient&idpEntityID=http://IDP01.bbb.local/adfs/services/trust&binding=HTTP-POST|https://sso.aaa.local:8443/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&NameIDFormat=transient&idpEntityID=http://IDP01.bbb.local/adfs/services/trust&binding=HTTP-POST]

Via HTTP-Artifact method

[https://sso.aaa.local:8443/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&NameIDFormat=transient&idpEntityID=http://IDP01.bbb.local/adfs/services/trust&binding=HTTP-Artifact|https://sso.aaa.local:8443/opensso/saml2/jsp/spSSOInit.jsp?metaAlias=/sp&NameIDFormat=transient&idpEntityID=http://IDP01.bbb.local/adfs/services/trust&binding=HTTP-Artifact]

Alternatively you can first go to the ADFS IDP. This is called an IDP Initiated Login.

ADFS 2.0 offers various authentication methods, such as Forms authentication, which will always offers a user/password screen. But it also offers IWA to authenticate internally.

If you would navigate directly to the IDPInitiatedLogin.aspx page you will have the opportunity to logon only to ADFS or Logon to ADFS and redirect directly to one of the configured Service Provider Trusts.

There is also a way of doing this without the Sign-In and go directly to one of the configure service providers by providing the service provider as a query parameter:

https://idp01.bbb.local/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://sso.aaa.local:8443/opensso

https://idp01.bbb.local/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=https://sso.aaa.local:8443/opensso

This will automatically log you into ADFS and into OpenAM.