Step by Step guide to set up Shibboleth as an IDP on Windows:

IDP-Identity Provider, SP – Service provider

Shibboleth is an open-source identity federation solution that’s used in research and education
communities worldwide

In order to quickly set up a demo environment in EC2, the cloudformation template for single-server
AD template can be used. This template is supposed to do the heavy lifting of deploying a Microsoft
Window Server 2008 R2 instance and configuring it as an AD domain controller. This step takes about 15
to 20 minutes to complete.

➢ Make sure you have created an EC2 key pair before bringing the stack up
➢ The template is loaded on to S3 and then pulled from there to create a stack
➢ The following are the values that need to be provided before creating the stack
o DomainDNSName. Use corp.example.com.
o DomainnetBIOSName. Use CORP. This will be the domain for the Administrator user
that the template creates (CORPAdministrator).
o KeyPairName. Enter the name of a key pair in EC2. (Don’t enter a .pem file name; use
the name as reported by EC2.) You’ll use the private key in the key pair to decrypt the
password for logging in to the EC2 instance.
o SourceCidForRDP. Enter the IP address (with a 32-bit prefix, e.g. /32) for the computer
from which you’ll use Remote Desktop Connection to access the EC2 instance.
➢ After the cloudformation template is created, log into the instance by generating the admin user
password by uploading the keypair.
➢ Next, using the Active Directory Users and Computers, create an AD user named ‘EQTest’. In the
User logon name box, enter EQTest. After that, create two AD groups named AWS-Production
and AWS-Dev and add EQTest to these two groups.
➢ Right-click the name EQTest, and then click Properties. In the General tab of
the Properties window, enter eqtest@example.com in the E-mail text box.
 ➢ The output of cf template is like this:

DomainControllerD ec2-18-206- Public DNS name of Active Directory server for

NSName 124- RDP connection
77.compute-
1.amazonaw
s.com

DomainAdmin test\EQTest Default domain administrator account

DomainAdminPass Please
word retrieve
Administrato
r password
of the
instance

DomainControllerIP 172.31.89.14 Private IP address of Active Directory server which

8 is also a DNS server

➢ Make sure you open up the following security groups if you are about to log into the instance
from Enquizit office location.
✓ RDP - 128.103.150.22/32
✓ HTTPS - 72.221.12.238/32
✓ ALL TCP - 72.221.12.238/32

Initial Preparation on the instance:

1) Download a copy of Oracle Java 8 (1.8) SE JDK for Windows from the Oracle website
a. Choose JDK Download and download the relevant version for your OS.
i. Windows 64-bit - jdk-nnnnn-windows-x64.exe (where nnnn reflects the version
number).
ii. Windows 32-bit - jdk-nnnnn-windows-i586.exe (where nnnn reflects the version
number).
b. Whilst JRE may work, only JDK is supported according the the IdP3 System
Requirements.
2) For Java versions earlier than 1.8u161, then download a copy of Java Cryptography Extension
(JCE) Unlimited Strength Jurisdiction Policy Files for JDK/JRE 8 from the Oracle website
a. This will be a single download named jce_policy-8.zip
b. JCE is required for some Service Providers (SPs) that may need to use AES with 256-bit
keys, and is suggested in IdP3 Installation
3) Download a copy of Shibboleth IdP for Windows from the Shibboleth Project
a. Choose the relevant version for your OS.
i. Windows 64-bit - shibboleth-identity-provider-nnnnn-x64.msi
ii. Windows 32-bit - shibboleth-identity-provider-nnnnn-x86.msi
 4) Create a user in 'Active Directory Users and Computers' for the Shibboleth IdP to search your
Active Directory with.
a. It should have the minimum level of privileges, so only a member of 'Domain Guests'
i. Under Properties, Account, it should have
ii. 'User cannot change Password' ticked
iii. 'Password never expires' ticked
iv. 'User must change password at next logon' should be not be ticked
v. Account Expires: Never
b. Make a note of the username 'User login name' and password
5) Choose a DNS name and scope for your IdP
a. When picking a DNS name for your Shibboleth IdP, consider using a name that reflects
the function such as idp.example.ac.uk rather than the software deployed such
as shibboleth.example.ac.uk.
b. You will need to decide on a Scope for your IdP to use when using scoped attributes. In
most cases you will use your existing domain e.g. example.ac.uk.
c. Your entityID and Scope need to comply with our entityID policy and our Metadata
Registration Practice Statement. In practice, this means ensuring that the DNS name
used is for a domain registered to the relevant legal entity.
d. Ensure the appropriate DNS records are created in the external DNS and if required in
any internal DNS for the DNS name of the IdP.
6) Firewall rules
a. Your IdP will require the following open from anywhere inbound to the IdP TCP port 443
(https) and TCP port 8443 (alt-https / IdP Backchannel) to the IdP.
b. The IdP will itself need access to TCP port 80 (http) for outbound for the UK federation
metadata.
c. The IdP will need access to the appropriate ports for LDAP on the Active Directory
Domain Controllers. It is likely to need one or more of the following (whilst configuring
and testing you want to open all of these)
i. TCP port 389 for LDAP (plaintext and/or startTLS)
ii. TCP port 636 for LDAPS (SSL/TLS)
iii. TCP port 3268 for LDAP Domain Controller Global Catalogue (plaintext and/or
startTLS)
iv. TCP port 3269 for LDAPS Domain Controller Global Catalogue (SSL/TLS)

These security groups are already part of the instance from what was created as
part of the stack, but make sure to validate the same.

Installation:

➢ Install Java
o If you downloaded the files above on another machine, then copy them to your
Windows server.
o Start by installing Java using the default settings.
 o Once Java is installed, then locate the install path for Java JRE using 'File Explorer', for
example C:\Program Files\Java\jdknnnn_nnn\jre. The path you are looking for will have
a bin folder within it.
o For Java versions earlier than 1.8u161, take the jce_policy-8.zip and extract the
individual local_policy.jar and US_export_policy.jar files to the C:\Program
Files\Java\jdknnnn_nnn\jre\lib\security folder, this will overwrite two existing files of
the same names.
o Setup a JAVA_HOME environment variable to point to the Java installation
o Within 'File Explorer', choose 'This PC' and right click 'Properties'
o On the Left-hand panel - Choose 'Advanced System Settings', at the bottom of the
'Advanced' Tab choose 'Environment Variables'
o Under 'System variables' choose 'New...'
o Variable name: JAVA_HOME
o Variable value: C:\Program Files\Java\jdknnnn_nnn\jre
o Click OK

➢ Run Shibboleth Idp Windows installer

This installer will install Shibboleth and the Jetty (web server/Java container)
o Open the Shibboleth IdP installer file shibboleth-identity-provider-nnnnn-x64.msi

o On the 'Welcome page', choose 'Next'

o On the 'End-User License agreement', read and then choose 'I accept the terms in the
License Agreement', choose 'Next'
o On the 'Configure Shibboleth' screen
 oLeave the install folder as-is.
oMake sure that 'Install Jetty' and 'Configure for Active Directory' are ticked.
oIn 'Choose the DNS Name for this IdP' enter the Fully Qualified Domain Name (FQDN) of
the IdP, this will be a registered DNS name, which you will need to ensure exists in DNS.
An example would be idp.example.ac.uk
o In 'Scope' enter the Fully Qualified Domain Name of your organization, this typically the
same DNS name you use publicly for instance for email or web services.
o Configure for Active Directory
o In 'Specify the Active Directory Domain:' enter the FQDN of the Active Directory domain.
Note: that whilst this can reflect a registered domain name e.g. example.ac.uk, it might
be a non-registered domain like example.local
o Enter the username and password, which have been generated under Preparation step
4.
o At this stage, the IdP is installed, but will require further configuration within the
%{idp.home} folder, on Windows this is usually C:\Program Files(x86)\Shibboleth\IdP
➢ Install tomcat6 if not already available (apache-tomcat-8.0.53-windows-x64)

Once the installation is complete, you can see three folders under the Shibboleth folder in the
mentioned location (Idp, Jetty and ProcRun) if you have enabled Jetty configuration and Active
Directory. All the three folders will have a version of “shibd_idpw.exe”. For this demo, the one under Idp
folder was used.

Information on setting up through Jetty:

In a production environment, the next step would be to acquire a public key certificate from a
certifying authority (CA) and use it to secure the communication between Shibboleth and AD. For
demonstration purposes and because both AD and Shibboleth are running on the same EC2 instance,
you can disable the need for a certificate by modifying the Shibboleth configuration using these steps:
1. Go to the following folder:
C:/Program Files (x86)/Internet2/Shib2IdP/conf
2. In the login.config file, set tls=”false”.
3. In the attribute-resolver.xml file, set useStartTLS=”false”.
4. At the command line in the EC2 instance, run the following two commands:
5. sc stop tomcat6
6. sc start tomcat6
Shibboleth is now ready to act as the identity provider.

Some Java server installations are in the of a .tarball. For obvious reasons these installations from a
tarball does not populate any registry settings which means that the Jetty installation cannot locate the
correct jvm to run. This means that the shibd_idp does not start.

To fix this:

1. run shibd_idpw

2. Go to the "java tab"

3. Unclick "Use Default"

 4. Under "Java Virtual Machine" browse to %JAVA_HOME%\jre\bin\server\jvm.dll (for
instance: C:\Program Files\java\jdk1.8.0_25\jre\bin\server\jvm.dll)

Quick Test:

To test if the above service is running, run this PS

1) sc interrogate shibd_idp

2) To suppress firewall exceptions:

✓ msiexec /i shibboleth-identity-provider-3.xxx.msi NO_FIREWALL_EXCEPTION=true

Setting up AWS as the SP (Service provider):

For this, we need the metadata document of the identity provider. Under the Idp folder, you can see a
metadata folder. This will have the entityID based on your hostname and domain name. The below links
must show the same metadata (first option worked)

https://win-ft8v1v39c7s.enquizit.com/idp/shibboleth
https://win-0gps911ldh4.enquizit.com/idp/profile/Metadata/SAML
https://win-0gps911ldh4.enquizit.com/Shibboleth.sso/Metadata

This metadata file has to be imported into AWS IAM Identity Provider. Go to the AWS Console IAM and
choosing Create Provider under Identity Provider. Choose SAML as the Provider Type and upload the
metadata.xml file to finish the creation.

Next step is to create the IAM roles that define that federated users will have. You’ll create two roles—
Shibboleth-Production and Shibboleth-Dev. Be sure to use these names, because later parts of this
walkthrough assume these names. The idea is that you’ll establish a one-to-one mapping between the
AD groups you created earlier and IAM roles in your AWS account; the mapping will be based on a
naming convention. When everything is configured, a user in AWS-Production group will be able to
perform only AWS actions permitted by a role named Shibboleth-Production, and users in AWS-
Dev group will have the permissions defined in the Shibboleth-Dev role. For the Shibboleth-
Production role, use the Administrator Access policy template to give the role permissions. For
the Shibboleth-Dev role, use the Read Only Access policy template.

Configure Shibboleth to use AWS as a relying party:

The identity provider does not know about the service provider yet, so the next step is to add AWS as a
relying party in Shibboleth. In the EC2 instance, open the following files make changes:

“C:/Program Files (x86)/Shibboleth/Idp/conf/relying-party.xml” under the default relying party)

<RelyingParty id="urn:amazon:webservices" provider="https://win0gps911ldh4.enquizit.com/idp/shibboleth"
defaultSigningCredentialRef="IdPCredential">
<ProfileConfiguration
xsi:type="saml:SAML2SSOProfile"
includeAttributeStatement="true"
assertionLifetime="PT5M" assertionProxyCount="0"
signResponses="never" signAssertions="always"
 encryptAssertions="never" encryptNameIds="never"
includeConditionsNotBefore="true"
maximumSPSessionLifetime="PT1H" />
</RelyingParty>

Under metadata-providers.xml “C:/Program Files (x86)/Shibboleth/Idp/conf/metadata-providers.xml”,

add this snippet:

<MetadataProvider id="HTTPMetadata"
xsi:type="FileBackedHTTPMetadataProvider"
backingFile="C:\Program Files (x86)\Shibboleth\IdP\metadata\idp-metadata.xml"
metadataURL="https://win-ft8v1v39c7s.enquizit.com/idp/shibboleth">
<MetadataProvider id="AWS"
xsi:type="FileBackedHTTPMetadataProvider"
metadataURL="https://signin.aws.amazon.com/static/saml-metadata.xml"
backingFile="/path/to/shibboleth-idp/metadata/aws.xml" />

Configure Shibboleth to generate AWS-specific assertions:

The final step is to set some additional attributes that AWS will look for in SAML assertion: awsRoles and
awsRoleSessionName.

These can be added in ‘attribute-resolver.xml’ found under C:/Program

Files(x86)/Shibboleth/Idp/conf/attribute-resolver.xml. The following contents can be added before the
DataConnector element by replacing the accountID and your AWS account ID.

<AttributeDefinition xsi:type="Simple" id="awsRoles" xsi:type="ad:Mapped"

sourceAttributeID="memberOf">
<Dependency ref="myLDAP" />
<AttributeEncoder xsi:type="enc:SAML2String"
name="https://aws.amazon.com/SAML/Attributes/Role" friendlyName="Role" />
<ad:ValueMap>
<ad:ReturnValue>arn:aws:iam::<AccountNumber>:saml-provider/Shibboleth, arn:aws:iam::
AccountNumber:role/SHIBBOLETH-</ad:ReturnValue>
<ad:SourceValue>CN=AWS-([^,]*),.*</ad:SourceValue>
</ad:ValueMap>
</AttributeDefinition>

<AttributeDefinition xsi:type="Simple" id="awsRoleSessionName" xsi:type="ad:Simple"

sourceAttributeID="mail">
<Dependency ref="myLDAP" />
<AttributeEncoder xsi:type="enc:SAML2String"
name="https://aws.amazon.com/SAML/Attributes/RoleSessionName"
friendlyName="RoleSessionName" />
</AttributeDefinition>
Uncomment the attribute definitions for Core, inetOrgPerson, and eduPerson in the IdP's conf/attribute-
resolver.xml file.

Comment these under Data Connectors in the same file:

<StartTLSTrustCredential id="LDAPtoIdPCredential" xsi:type="sec:X509ResourceBacked">

<sec:Certificate>%{idp.attribute.resolver.LDAP.trustCertificates}</sec:Certificate>
</StartTLSTrustCredential>
This is because it may cause an error on startup if the associated certificate is not present in the
'credentials' directory.

Also, under ldap properties file under Idp folder, make sure the below fields are set to false

## Connection properties ##
idp.authn.LDAP.ldapURL = ldap://localhost:10389
idp.authn.LDAP.useStartTLS = false
#idp.authn.LDAP.useSSL = false

Under attributes-resolver-ldap, comment the SSL related lines:

<DataConnector id="myLDAP" xsi:type="LDAPDirectory"

ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
baseDN="%{idp.attribute.resolver.LDAP.baseDN}"
principal="%{idp.attribute.resolver.LDAP.bindDN}"
principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
<-- useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}" -->
connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}"
<-- trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}" -->
responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}">

The first attribute definition (id=”awsRoles”) configures Shibboleth to parse the memberOf attribute of
the authenticated user to look for groups starting with “AWS-” (ad:SourceValue tag). Based on this,
Shibboleth sets the awsRoles attribute in the assertion to include the corresponding role name that
starts with “Shibboleth-” (ad:ReturnValue tag). For example, if authenticated user Bob is a member of
AD group AWS-Production, the awsRoles attribute in the assertion will include a role with the following
name: arn:aws:iam::accountid:role/Shibboleth-Production.

The second attribute definition (id=”awsRoleSessionName”) configures Shibboleth to use

the mail attribute of the authenticated user to set the value of the awsRoleSessionName attribute in the
assertion. This is why it’s essential for the AD user to have an email address defined in AD, so that this
value is not empty in the assertion.

Now that Shibboleth is configured to generate the required AWS attributes, you need to ensure that
these attributes get included in assertions. Open the following file:

“C:/Program Files (x86)/Shibboleth/Idp/conf/attribute-filter.xml”

Add the following snippet just before the closing tag of the AttributeFilterPolicy element
with id=”releaseToAnyone”. (The snippet you’re adding must follow the existing content that’s already
inside the AttributeFilterPolicy element.)

<AttributeFilterPolicy id="AWS">

<AttributeRule attributeID="awsroles">
<PermitValueRule xsi:type="ANY" />
</AttributeRule>

<AttributeRule attributeID="awsRoleSessionName">
<PermitValueRule xsi:type="ANY" />
</AttributeRule>

</AttributeFilterPolicy>

Under “C:\Program Files (x86)\Shibboleth\IdP\messages”, you can add the message you want to display
on the startup page.

# You can define message properties here to override messages defined in

# system/messages/ or to add your own messages.
idp.title = Enquizit Login
idp.logo = ../../logo.jpg
idp.logo.alt-text = Enquizit Logo
idp.footer = &copy; Enquizit Inc.
Under the same Idp folder, you can also add a logo for your company/organization. This logo can be
added to your starting page.

Sign in using identity provider-initiated flow:

In order for all the configuration changes to take effect, you need to restart Tomcat. At the command
line in the EC2 instance, run the following two commands:

- sc stop tomcat6
- sc start tomcat6

After that, on your EC2 instance, point your web browser to the following URL. Replace hostname with
the full computer name of your EC2 instance.

https://hostname/idp/profile/SAML2/Unsolicited/SSO?providerId=urn:amazon:webservices

As before, you’ll see a message about a problem with the website’s security certificate.
Click Continue to this website.

You will see the default Shibboleth login page as shown in the following screenshot. Enter the user
name and password for Bob and then click Login.

If you don’t see this (for example, if you see a 404 message), do this:
 • Double-check that you updated the configuration files correctly, as described in the previous
section.
• Check the Shibboleth log file (C:/Program Files (x86)/Shibboleth/Idp/logs/idp-process.log).
For example, an “invalid content” error might indicate that a configuration file could not be
parsed correctly.

References:

1) https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-
aws-management-console/
2) https://www.ukfederation.org.uk/content/Documents/Setup3IdPWindows
3) https://wiki.shibboleth.net/confluence/display/IDP30/WindowsInstallation