Child pages
  • Windows Service Provider
Skip to end of metadata
Go to start of metadata

Section 0: VM Preconfiguration

Complete the preparation required in Windows Preparation for Participants before you continue.

Notes: This document is not meant to be a complete discussion on anything you might ever do with an SP. There are many topics of potential interest that are left out of this document in an attempt to keep it more focused on getting a basic SP up and running. This document is meant as a guide to help you get your SP working and in understanding how to care for it. Please read the official Shibboleth project documentation (linked to occasionally from this document) for a deeper understanding.

Section 1: Install

1. Understand the Shibboleth SP
2. Download the Shibboleth SP software
3. Install the Shibboleth SP software on your web server

4. Basic IIS configuration
  • First, you may want to disable the Windows firewall or, at a minimum, open port 8443 for the SP.
  • Next, you'll need to integrate Shibboleth with IIS.  This is done by running the following commands from the c:\windows\system32\inetsrv directory in an administrative command prompt:
appcmd install module /name:ShibNative32 /image:"c:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" /precondition:bitness32
appcmd install module /name:ShibNative /image:"c:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" /precondition:bitness64
5. Verify that your new Shibboleth SP is alive

  • Objective:
    • Successfully load the SP's "Status" page
  • Tasks:
    • First, start/restart IIS on your server to make sure the Shibboleth ISAPI filter is loaded (you can just run iisreset from a command prompt)
    • Next, start/restart the Shibboleth service (using the Windows Services MMC)
    • Try accessing the URL from a command prompt inside your VM:

      curl -k

      cURL is installed as part of the Shibboleth SP distribution. If you are using PowerShell, you may need to invoke curl as curl.exe. This is because some versions of PowerShell create a curl alias that overrides the installed version. This should not be necessary when using a standard Windows command prompt.

      Note that handler URLs such as /Shibboleth.sso/Status are case sensitive. If you see a 404 error or a shibsp::ConfigurationException page with the message "Shibboleth handler invoked at an unconfigured location," Check that your URL exactly matches the example above, and make sure it does not have a trailing slash.

    • The status handler will display a lot of build and configuration information about your SP. It won't be immediately useful or meaningful to you, but it does show that your SP is operational.
    • The status handler is protected by an IP address ACL, which means you need to either perform this task from the web server itself, or edit the ACL for the /Status handler in C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml. Keep in mind that the list is space delimited.

      <Handler type="Status" Location="/Status" acl=" ::1"/>

      You may need to add the IPv6 loopback address - ::1 - to this ACL as well, as shown in the above example.

      You can also access the status page by adding your laptop's IP address to the ACL and visiting, which is a more common example for monitoring purposes. An easy way to ensure that you've added the right IP to the ACL is to source it from the IIS access logs.

  • Resources:
  • Success Factors:
    • Able to successfully load the SP's status page
6. Understand the files and directories of the SP

  • Objective:
  • Detail:
    • C:\opt\shibboleth-sp\etc\shibboleth
      • The main directory for configuration files for the Shibboleth SP
    • C:\opt\shibboleth-sp\sbin\shibd
      • This is the shibboleth daemon
      • It is useful to run it from the command line with the -check option to check your configuration for errors before attempting a service restart (you should see "Overall configuration is loadable...")
    • C:\opt\shibboleth-sp\var\log\shibboleth
      • This is the main directory for Shibboleth SP log files
      • shibd.log is the main log file and the first place to look for errors
      • transaction.log contains summary information about each transaction processed by the SP
    • C:\opt\shibboleth-sp\lib\shibboleth
      • The location of the Shibboleth SP extensions/modules
    • C:\opt\shibboleth-sp\etc\shibboleth\apache22.config (filename varies depending on Apache version; choose the one that matches the version you are using)
      • The location of Shibboleth SP-specific Apache configuration directives. This file is designed to be included at start time in your main Apache config.  It will not be needed for this training since we are not using the Apache web server.
    • the files in the C:\opt\shibboleth-sp\etc\shibboleth\dist subdirectory are copies of the original configuration files that shipped with the SP, in case you need to revert to a default version, or just want to refer back to them.
  • Success Factors:
    • Able to explain the different log files created by the Shibboleth SP and their location on the server.

Section 2: Configure

1a. Configure settings for the web server

  • Objective:
    • Configure Shibboleth to integrate with your web server
  • Tasks:
    • Verify the web site number (for this training, the default of 1 is correct).  You can get this number from the IIS Management app by clicking on 'Sites' on the left-side menu. Check the ID listed for "Default Web Site".
    • Edit the <ISAPI> element in shibboleth2.xml (towards the top of the file)
    • Enter for the name that maps to site id=1
    • Make note of the safeHeaderNames parameter on the <ISAPI> element.  When safeHeaderNames is true, any dashes or underscores will be removed from the header names that apps see, even if your attribute-map.xml file has configured attributeIDs with dashes or underscores. UPDATE: This is no longer true when using ServerVariables with the new IIS7 module that ships with the Shibboleth SP 3.0+.

    • Next, find the <RequestMapper> section (should be the next thing in the file after the <ISAPI> block). Change the value of <Host> (8th line in the example below) to match your chosen hostname and also add the port and scheme:

      <RequestMapper type="Native">
                  The example requires a session for documents in /secure on the containing host with http and
                  https on the default ports. Note that the name and port in the <Host> elements MUST match
                  Apache's ServerName and Port directives or the IIS Site name in the <ISAPI> element above.
                  <Host name="" scheme="https" port="8443">
                      <Path name="secure" authType="shibboleth" requireSession="true"/>
                  <!-- Example of a second vhost mapped to a different applicationId. -->
                  <Host name="" applicationId="admin" authType="shibboleth" requireSession="true"/>
  • Resources:
  • Success Factors:
    • Shibboleth is properly configured to interoperate with your web server (ultimate proof will come with final testing).
1. Create your default SAML entity ID

  • Objective:
    • Configure an appropriate default SAML entity ID for your SP
  • Tasks:
    • Set the entityID parameter, located in the <ApplicationDefaults> element in c:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml. Be sure you're working on the opening tag.
    • The best bet is to just follow the suggested name, with appropriate modifications for your hostname (i.e.
  • Resources:
  • Success Factors:
    • Default SAML entity ID is properly defined and configured. This can be validated by looking at <Application id="default" entityID=""/> as returned by the Status handler if you feel so inclined.
3. Configure the SP to require SSL for cookies

  • Objective:
    • Configure the Shibboleth SP to set secure cookies
  • Tasks:
    • Locate the <Sessions> element inside the <ApplicationDefaults> element within shibboleth2.xml
    • The Sessions element contains session timeouts and settings that affect how the SP responds to most requests directly issued to it by clients. Most of those default settings work fine, but the default is not to force SSL/TLS for cookie and assertion presentation. As these are bearer tokens, if they are stolen, then they can be used to impersonate an authenticated user. We would like to prevent that.
    • It's good practice to require secure cookies by forcing cookieProps="; path=/; secure; HttpOnly", which can be done through the shorthand cookieProps="https". Even if you have disabled http:// on your server, this will tell the browser to only deliver cookies over SSL, further reducing the chance that user error will expose a cookie.

      <Sessions lifetime="28800" timeout="3600" checkAddress="false"
                  relayState="ss:mem" handlerSSL="true" cookieProps="https">
    • If you can't convince an application administrator to only require access over https://, then don't set cookieProps to secure. However, you can at least set handlerSSL="true", which will force the assertion itself to be delivered over SSL. But since the assertion over HTTPS is arguably better secured than a cookie over HTTPS, you should really talk more to the application administrator.
  • Resources:
  • Success Factors:
    • The SP sets cookies with the secure flag. These session cookies will not be set until a user successfully logs in, so it's hard for you to validate this now, but later you can look at the contents of _shibsession cookies in the browser.
4. Define/Load a metadata source

  • Objective:
    • Configure a source of metadata for your SP and, in production scenarios, verify the signature on the metadata and require it to have a maximum validity period.
  • Tasks:
    • Add the metadata provider described below to shibboleth2.xml.
    • For production, you should require digitally signed metadata and you should validate it.
    • You should also require a validUntil parameter in the metadata and specifying a "reasonable" value for maxValidityInterval is advisable.
    • For this training, your SP's MetadataProvider element will look like this. Add it next to the example, commented-out Example of locally maintained metadata, MetadataProvider element.

      <!-- Example of locally maintained metadata. -->
      <MetadataProvider type="XML" validate="true" path="partner-metadata.xml"/>
      <!-- Classroom metadata -->
      <MetadataProvider type="XML" url=""
       backingFilePath="ShibTrain1-metadata.xml" reloadInterval="7200" />

      The backingFilePath is generally a relative path, and that path depends on the OS on which the SP has been installed and the manner in which the installation occurred.  In most cases, you'll find it in  C:\opt\shibboleth-sp\var\cache\shibboleth.  Absolute paths may be used if you have some reason to do so.

    • You can test the resulting configuration by running the mdquery utility from the command line. This command will use the SP's configuration as a list of metadata sources, and it will search through all those sources for string matches. You should expect to see a couple pages of XML that describes the IdP completely to your SP, including its entityID, certificates and endpoints.

      C:\opt\shibboleth-sp\bin\mdquery -e -idp -saml2

      There is also a special endpoint at /Shibboleth.sso/DiscoFeed that exposes the list of identity providers that the SP recognizes. Some discovery interfaces can retrieve this, and further prune the list of options by presenting the union of providers the DS trusts and providers the SP trusts to the user.

  • Resources:
  • Success Factors:
    • SP has successfully loaded a metadata source. This can be confirmed by running mdquery, or checking for a file in the backingFilePath that you used.
5. Configure Session Initiation

  • Objective:
    • Configure the SP to use the classroom Discovery Service and IdP to start new user sessions
  • Tasks:
    • In the SSO element in C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml, modify the SSO element's discoveryURL="" URL to be Also, modify the default entityID to be The successfully modified SSO element will look like this:

      <SSO entityID=""  discoveryProtocol="SAMLDS"
             SAML2 SAML1
    • The SSO handler will send users, by default, directly to the test IdP to authenticate there. If there were no default entityID defined or provided as part of the web environment or query, they would be sent to the Discovery Service (DS) next.
    • You can use query strings and other methods to send users directly to a specified IdP only for certain requests. There are examples in the wiki page below.
  • Resources:
  • Success Factors:
    • Requests for Shibboleth-protected URLs are successfully redirected to the Test IdP. This can be validated by going to if you like, but you'll just be presented with an error page because the rest of the configuration process is incomplete.
6. Adjust/configure the attribute-map.xml file

  • Objective:
    • Configure/uncomment the attributes that your applications will need in the attribute-map.xml configuration file (for the class, just uncomment every Attribute element in this file, except the 'SCHAC attributes'; however, watch out for deprecated configuration editions for certain attributes. Each attribute definition must have at most one decoder, so if you uncomment some deprecated decoders too [in particular, eduPersonTargetedID], you will experience errors on start).
  • Tasks:
    • Make sure that all attributes needed by your applications protected by this SP are defined in the attribute-map.xml file in /etc/shibboleth.. Most commonly used attributes are already defined in the file and just need to be uncommented. Any local or organization-specific attributes used by your applications will also need to be defined in this file, and the SAML names must match those configured at the partner IdP(s).
    • attribute-map.xml functionality may be thought of in many ways as the obverse of the identity provider's attribute-resolver.xml.
    • The reason these are commented out by default, is that this part of the SP's code must run on every request. The fewer attributes that it needs to iterate through, the faster the SP – and the rest of the web server – is. Practically speaking, though, this will not be an issue in most deployments, since the performance impact is not large.
  • Resources:
  • Success Factors:
    • SP is able to process and map all needed attributes. This can be seen in the SP's shibd.log with log level set to DEBUG (per the next step), but will be most obvious later when you test SSO.
7. Turn on DEBUG-level logging in shibd.logger

  • Objective:
    • Help us help you by increasing the verbosity of shibd.log to DEBUG
  • Tasks:
    • Edit C:\opt\shibboleth-sp\etc\shibboleth\shibd.logger and change the log4j.rootCategory to DEBUG
  • Resources:
  • Success Factors:
    • DEBUG-level information begins appearing in c:\opt\shibboleth-sp\var\log\shibboleth\shibd.log
8. One Last Check...

  • Objective:
    • After the configuration changes, confirm that your SP is still able to load its configuration (and thus is operating properly)
  • Tasks:
    • Use shibd from the command line to check your configuration. You can do this at any time, and it's especially useful if your web server appears to be unresponsive.
      • C:\opt\shibboleth-sp\sbin\shibd -check
      • You should see the words overall configuration is loadable, or a fascinating error message.
      • check console for non-fatal problems is a placeholder message to ensure that deployers check appropriate logging facilities (the command line window is used for severe cases, so it's obvious) for WARNs or ERRORs indicating configuration mistakes that aren't severe enough to prevent shibd from initializing, but are severe enough to cause problems in actual operation.
    • Restart your web server (iisreset) and the Shibboleth service (Services MMC)
    • Check the status page again
      • curl -k
  • Resources:
  • Success Factors:
    • The shibd check and status page loads both complete successfully
9. Provide your SAML metadata to a federation or IdP so that others can use your new SP

  • Objective:
    • Provide your SP's default SAML metadata to an IdP or federation (the administrator's machine, in this case)
    • Retrieve your SP's default metadata from the Metadata Handler, located by default at Make sure to use the right hostname, because it's used by the SP to generate its own metadata. We'll discuss why later.
      • Use the command curl -o metadata.xml -k https://<My.Special.Name>:8443/Shibboleth.sso/Metadata, or open the URL with a web browser and save the file when prompted.
    • Upload the copy of your SP's metadata at the classroom metadata aggregator page:
    • The upload page requires a password.  The classroom instructors will communicate the upload password to you.
    • Classroom metadata is built every 2 minutes.  This is designed as a special test for the impatient, so please wait a couple of minutes before trying to test your new SP.
    • This metadata file is generated dynamically by the SP by polling its own configuration. This will work fine for most basic deployments, but if you have any special configurations and/or virtual hosts, you will need to configure your metadata manually (though you can typically use this file as a starting point).
  • Resources:
  • Success Factors:
    • Your SP's SAML metadata is visible to all the IdPs in the training federation, including the training IdP (once your metadata is added to the training metadata). If you feel the need to validate this, you can access and wade through the XML looking for your entry. Or you can just wait a little while and go on to the next step.

Section 3: Simple Resource Protection

1. Test with your SP's default /secure directory

  • Objective:
    • Authenticate successfully to your SP using the classroom's test IdP
  • Tasks:
    • Access (with the source page located at c:\inetpub\wwwroot\secure\index.aspx; please verify that the file is there before testing). If everything is configured well, you will be asked to authenticate at the test IdP. After authenticating, you should be granted access to your secure resource (you should see user-specific attributes like eppn, givenName, sn, uid, etc). If you receive any error or other unexpected outcome, please look demotivated and raise your hand and a trainer will be with you shortly.
    • If your unexpected outcome includes Error Message: SAML 2 SSO profile is not configured for relying party <yourEntityID>, then your SP is not yet recognized by the training IdP (just wait for the metadata to sync up).
    • If your unexpected outcome appears to be a perpetual loop, or a stalled browser, please stop your inadvertent load test and ensure that you are accessing your SP over https:// (note the 'S')
  • Resources:
  • Success Factors:
    • You can access the /secure directory after having authenticated successfully
    • If you would like to see what the SP knows about you, you can access the Session Handler at from the web browser that has the active session.  You can also toggle the display of actual attribute values and content type by setting showAttributeValues to true in the Session handler (in shibboleth2.xml). This should generally be disabled in production to limit information leakage.. 
2. Protect a new resource

By default, Shibboleth is installed with the /secure path already Shib-protected.

  • Objective:
    • Configure a new URL path to require a Shibboleth session
  • Tasks:
    • Goal: Create and protect a new directory at logical path '/testscript' and redirect the user to the classroom DS when starting new sessions, rather than directly to the classroom IdP.
    • Edit the <RequestMap> element in shibboleth2.xml
    • Add a <Path> element for the new path to protect (testscript) inside the <Host> element. This will activate the Shib ISAPI module to protect a new test script that we'll create later.

      Protect new path
      <Path name="testscript" authType="shibboleth" requireSession="true" exportAssertion="true" />
    • Disable direct-to-IdP session initiation.  this is done by removing the entityID attribute in shibboleth2.xml's <SSO> element. The SP will iterate over inbound requests to see if an entityID is present anywhere. As there is no d default entityID present, nor an entityID supplied with the request, the SP will fall back to performing using the discoveryProtocol at the discoveryURL.

      <SSO discoveryProtocol="SAMLDS" discoveryURL="">
                         SAML2 SAML1
    • Restart the shibd service.
  • Success Factors:
    • You will be redirected to the classroom discovery service. If you select the InCommon Training IdP and log in, you should be redirected back to your script.
3. Copy the index.aspx test page to the new protected location
  • Create the testscript directory as a sub-directory of c:\inetpub\wwwroot\
  • Copy the index.aspx script from c:\inetpub\wwwroot\secure to this new directory
  • Restart IIS (iisreset) and the Shibboleth service (shibd)
  • Access the URL - you should see attributes (you may or may not be asked to authenticate, depending on whether or not you are logged in at the test IdP)
  • Pick InCommon Training IdP from the DiscoveryService interface.

Some basic guidance on enabling applications is available from

Section 4: Notes and "How-to" for a few popular apps

What to do when instructions mention Apache-specific directives

** Where integration notes mention Apache-specific configuration, just use the <RequestMap> section in shibboleth2.xml to make the equivalent configurations.  For example:
This Apache config:                                 ...can be configured for IIS in shibboleth2.xml by placing this in the <RequestMap> within the appropriate <Host> element:

<Location /pathname>                                                <Host name="">
   AuthType shibboleth                                                        <Path name="pathname" requireSession="true"/>
   Require shibboleth                                                  </Host>

For more info, see:

1. Moodle

2. Confluence

3. Mediawiki

4. Drupal

** See also the Shibbolized drupal walkthrough for the Linux SP in Section 4 on this page:

5. BlackBoard (a little old, but not much has changed)

Section 5: Advanced Topics

General advice for handling errors at the SP

  • DO NOT CRASH! The SP should positively avoid unstructured error messages (e.g., java stack traces or other system messages).
  • The SP should not return a generic statement about how IdPs should handle this type of problem. The SP operator should try to put him/herself in the place of the user.
  • The SP shouldn't be required (or tempted) to instantiate a workflow process for the user to follow in order to obtain access to the site.
  • The best approach is to tell the user specifically what steps to take in order to proceed (e.g., contact the SP help desk, obtain local login credentials, contact the IdP help desk, etc.).

Please don't use the Shibboleth logo as the primary error page logo. It is recommended that SPs host a branded error page with a look-and-feel consistent with the rest of the protected application. If there is an errorURL in IdP metadata, the SP should display a prominent link to the IdP’s advertised error page (given by the value of errorURL). Otherwise the SP should display contact information for the IdP’s administrative contact(s) (also taken from metadata) and give the user enough information to send a meaningful message to the administrative contact. The SP may actually send such a message on the user’s behalf (with user permission of course).

The previous recommendation presents a fairly high bar for the SP, at least initially. It presumes that the SP can parse IdP metadata, extract the needed information (errorURL, contact information, etc.), and display it dynamically on a branded error page. To alleviate this burden (while we develop helpful client-side tools), the SP can instead display a centralized error page offered by InCommon Operations as a service to the community.

1. Session Initiation
  • Required sessions

When accessing our resource at /secure and /testscript, Shibboleth forced us to create a session when we first accessed. This static, forced session initiation for a complete URL space is one mode of operation for Shibboleth.

  • Lazy sessions

More commonly used, perhaps, is the Lazy Session. This allows the application to decide when session creation should be initiated by sending the user to a special URL. This is how the Drupal plugin works.

  • Tasks: Protect /testscript using lazy sessions. (done in shibboleth2.xml)
  • Objective:
    • Change /testscript to no longer require a Shibboleth session, but to still require Shibboleth. Then, modify the testscript to have a link that will allow you to start a session.


<Path name="testscript" authType="shibboleth" requireSession="false" exportAssertion="true" />
    • Then either create a new .asp page or modify /testscript/index.asp with different links like this:


<title>Hello Shib World</title>
<a href="">
Make Me A Session</a><br/>
<a href="">
Make Me A Session and Skip the DS</a><br/>
<a href="">
End My Session</a><br/>
<!-- insert normal code for displaying attributes here - Request.ServerVariables("HTTP_REMOTE_USER") etc see index.asp-->

Next, try accessing Note the difference in environment variables before and after authenticating.

This is the most simple interface possible for lazy session initiation. You could front these links with buttons that go directly to an IdP (and even have multiple buttons for multiple IdP's) so long as you're not operating with many IdP's.

There are many alternatives available today for IdP discovery interfaces and integration. You can read about some of them in the Shibboleth Wiki's IdP Discovery article.

There is a primer on how to integrate an embedded discovery service (EDS) with an application. It's an excellent way to give the application freedom in implementation while making the interface itself as shared as much as possible.  The EDS is very simple, done entirely in javacript.  With a working Shibboleth SP, you can have a basic EDS running in under 5 minutes using a simple HTML page (see the link above if you'd like to try this on your VM in the class).

Getting session initiation right is the most important part of the federated user login experience.

An example of a great large-scale live discovery service can be found at the Shibboleth Wiki,

An example of a great small-scale live discovery interface can be found at the Five Colleges collaborative site at

An example of a slick discovery interface that may have accessibility limitations can be found at EDUCAUSE's website at

There's also plenty of scientific inquiry that has been conducted into discovery interfaces. If you have lots of free time, try perusing the ESPReSSO report from NISO or Google's work or the Publisher Interface Study by the University of Cardiff.

2. Accept users from a new IdP

We only have one IdP that can release attributes to your SP. However, there's a general use IdP that you can also use at TestShib (or SAMLTest).  OR 

Do not follow the TestShib configuration instructions. They are intended for novice deployers performing fresh installations. Please follow the steps below to add TestShib as another IdP for your existing SP.

Register your SP with TestShib.

Next, you need to load the TestShib IdP's metadata in shibboleth2.xml:

<MetadataProvider type="XML" url=""
             backingFilePath="testshib-providers.xml" reloadInterval="180000" />

We'll also need to configure session initiation to go to the TestShib IdP. Modify your test script (in /testscript) again to make this happen.

NOTE: Confluence (this wiki) sucks.  It refuses to correctly display the links in the script below, so they have an extra '\' in the URL before the colon to fool confluence - please re-type them correctly.

<title>Hello Shib World</title>

<a href="https\://\://">
Make Me A Session</a><br/>
<a href="https\://\://\://">
Make Me A Session with the TestShib IdP</a><br/>
<a href="https\://\://">
End My Session</a><br/>
<!-- existing code to dump attributes using Request.ServerVariables{"HTTP_REMOTE_USER") etc goes here -->
3. Direct-to-IdP Session Initiation

In many situations, you may have an application that serves a limited number of identity providers. Rather than doing full IdP discovery, it can be advantageous to send the users directly to their IdP by doing limited discovery on the application page itself. We're vivisecting test.asp again:

<title>Hello Shib World</title>
<p><a href="">
<center><img src="" /><br/><br/>
Make Me A Session with the TestShib IdP
<p><a href="">
<center><img src="" /><br/><br/>
Make Me A Session with the InCommon Training IdP
<td><a href="">
Make Me A Session with a Different IdP</a><br/></td>
<td><a href="">
End My Session</a></td>
<br/><br/><br/><hr/><!-- existing code to dump attributes using Request.ServerVariables{"HTTP_REMOTE_USER") etc goes here -->

Now imagine changing out the images for, say, school logos, and getting this in the hands of a competent web designer.

This is a highly effective discovery approach for smaller-scaled collaborations.

That said, it is much easier to use the embedded discovery service (EDS) - here's a how-to.

4. Authorization ACLs
  • Issue:
    • You may want to restrict access to certain users, based on specified values of certain attributes
  • Notes:
    • For any <Host> or <Path> element in the RequestMap in shibboleth2.xml, you can set an ACL that checks specified attributes for listed values.
    • Can be either in-line (within shibboleth2.xml) or in an external file (useful if you want to apply the same ruleset to more than one <Path> element).
    • For example, to limit access to an application to only Ohio State faculty or students, other than a single blacklisted person (, if they have authenticated with a password or a time-synchronized token, you might use a <Path> element like the following in your RequestMap element in shibboleth2.xml:

      <Path name="secure" authType="shibboleth" requireSession="true">
            <Rule require="affiliation"></Rule>
              <Rule require="user"></Rule>
              <Rule require="authnContextClassRef">urn:oasis:names:tc:SAML:2.0:ac:classes:Password</Rule>
              <Rule require="authnContextClassRef">urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken</Rule>
    • To reference the rule in an external file, the <Path> element would look like this:

      <Path name="secure" authType="shibboleth" requireSession="true" >
        <AccessControlProvider path="c:\opt\shibboleth-sp\etc\shibboleth\shibacl.xml" type="XML"/>
  • Resources:

Section 6: Discussion Topics

Once everyone is finished with the curriculum, we'll continue with Discussion Topics. Note that this link will take you to the Linux curriculum page. We'll point out any differences between the Linux and Windows versions as we proceed with the discussion. Please feel free to ask for clarification if needed.


  • No labels