Vladimir's general Shibboleth notes
From BeSTGRID
This is a place-holder page where I want to keep my notes at least vaguely related to Shibboleth. I hope this may be useful of others as well. But it's generally intended as a place for notes I consider useful for myself...
[edit] Signing XML documents
The MAMS testbed federation puts signatures into the federation metadata XML documents. The signatures, inserted at the beginning of the document, have a digest of the canonic form the the remaining on documents, a signature of the digest, and the certificate for the key used to create the signature.
I was looking at what are the steps to create such signatures. The Apache XML Security project, http://xml.apache.org/security/, provides a Java and C library which allow to handle, and also create signed XML document. (The C library project is at http://xml.apache.org/security/c/)
I was looking for command-line tools which could be used to sign XML documents in a scripting environment. The C library (which is compiled as a part of installing the Shibboleth SP) has the templatesign tool. The tool needs a template for the signature to already exist as the first child of the top-level document. Then, the tool can be simple used as in the following example:
./templatesign --rsakey /etc/certs/mykey.pem "" --x509cert /etc/certs/mycert.pem /tmp/bestgrid-metadata.xml > /tmp/bestgrid-metadata-signed.xml
The template to be included is:
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"></ds:CanonicalizationMethod> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></ds:SignatureMethod> <ds:Reference URI=""> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#WithComments"></ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></ds:DigestMethod> <ds:DigestValue> </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> </ds:SignatureValue> </ds:Signature>
[edit] Shibboleth Logo on SP Error Pages
In the default installation of a SP, the error page does not display properly - it links to the Shibboleth stylesheet and logo at an non-existent location, /shibtarget/logo.jpg and /shibtarget/main.css.
The locations are configured in shibboleth.xml - however, in order for them to be accessible, the same names must be aliased to local files in the httpd configuration.
Following the configuration on the BeSTGRID wiki, I will configure both at "/shibboleth-sp" in shib-sp.conf on RedHat and mod_shib.conf on Debian/Ubuntu.
The following httpd configuration fragment makes the logo and stylesheet accessible. Note that the path to the resources may vary with the system is - the following works on systems where the Shibboleth SP is installed into /usr/local/shibboleth-sp, according to the MAMS instructions.
<IfModule mod_alias.c>
<Location /shibboleth-sp>
Allow from all
</Location>
Alias /shibboleth-sp/main.css /usr/local/shibboleth-sp/doc/shibboleth/main.css
Alias /shibboleth-sp/logo.jpg /usr/local/shibboleth-sp/doc/shibboleth/logo.jpg
</IfModule>
Also, shibboleth.xml has to be adjusted to use the new locations in error messages (and it also pays off to enter a real email address into the configuration):
<Errors session="/usr/local/shibboleth-sp/etc/shibboleth/sessionError.html"
metadata="/usr/local/shibboleth-sp/etc/shibboleth/metadataError.html"
rm="/usr/local/shibboleth-sp/etc/shibboleth/rmError.html"
access="/usr/local/shibboleth-sp/etc/shibboleth/accessError.html"
supportContact="vladimir.mencl@canterbury.ac.nz"
logoLocation="/shibboleth-sp/logo.jpg"
styleSheet="/shibboleth-sp/main.css"/>
[edit] Controlling Scope for an IdP
An IdP may be assigning a Scope to some attributes (such as eduPersonPrincipalName or eduPersonAffiliation). The metadata determines which values an IdP may use for the scope. The <shib:Scope> extension gives the permissible value (or optionally a regular expression). For the AAF federations, the scope is determined from the entityId of the organization - it is exactly the hostname specified as the last part of the entityId (see example below).
For an organization, the hostname of the IdP might take the form idp.organization.ac.nz, while the preferred scope would be just organization.ac.nz. The solution is to register the IdP with an entityId containing just the preferred value of the scope range (and to register the services running on the IdP with its actual hostname).
For the University of Canterbury, the organization's (and IdP's) entity Id is:urn:mace:federation.org.au:testfed:canterbury.ac.nz
This results into the <shib:Scope> extension having the value canterbury.ac.nz - while the hostname of the IdP still remains idp.canterbury.ac.nz.
[edit] Access control with Shibboleth: requesting a specific attribute
So far, the only form of access control used in the sample Shibboleth settings was requiring that a user authenticates with an IdP in the federation - and this plain membership was sufficient. It is possible to control access based on the presence of an attribute, or even a specific value of an attribute right at the level of Apache access control with the Shibboleth module.
The very simple form of doing that is:
<Location /secure>
AuthType shibboleth
ShibRequireSession On
# require valid-user
require user ~ ^.+$
</Location>
This specific example asks for the user variable to be set to any value - and any Shibboleth attribute can be used with the variable name it is assigned to in the Attribute Acceptance policy (AAP.xml). For more syntax on using the require directive, see the examples in the SP htaccess documentation on specific features implemented for the Apache require directive.
Users who do not have the attribute (or do not provide it), get the following error message (with the Shibboleth logo):
Authorization Failed Based on the information provided to this application about you, you are not authorized to access the resource at "https://idp-test.canterbury.ac.nz/secure/phpinfo.php" Please contact the administrator of this service or application if you believe this to be an error.
This form of control however may not be that user friendly - user would have to know to go either use Autograph to allow the release of the attribute, or talk to their IdP administrator to configure the attributes on the IdP.
Also note that this does not work with lazy sessions - in which case one immediately gets the same error message.
Further, note that care must be taken with overlapping <Location> access control blocks. These should be listed from the most-generic ("/") to the most specific (as "/secure" in the above example). Otherwise, the more relaxed settings on the generic one would override the more stringent settings on the specific one.
[edit] Enforcing Canonical Hostnames
Issue: when a SP is accessed by a URL other than it's cannonical one, the local WAYF redirector (Session Initiator) constructs a URL containing the non-canonical hostname (followed by /Shibboleth.sso) - and consequently, IdP produces a Session Creation Failure with the reason:
org.opensaml.SAMLException: Invalid assertion consumer service URL.
- Solution attempt 1: absolute shibboleth.xml handlerURL (does not work).
I thought I could fix it by editing <Sessions> element in shibboleth.xml, and change the attribute handlerURL from relative URL "/Shibboleth.sso" to an absolute URL containing the correct hostname.
Surprisingly, doing so results in a 50% failure rate in creating sessions, with the message
Session creation failure at (https://idp-test.canterbury.ac.nz/Shibboleth.sso/SAML/Artifact) Session Creation Error
displayed in the HTML response, and SP log saying:
2008-02-26 13:52:13 ERROR shibd.Listener [23] sessionNew: caught exception while creating session: SOAPHTTPBindingProvider::send() failed while contacting SAML responder: error:1408F06B:SSL routines:SSL3_GET_RECORD:bad decompression
and no useful information in the IdP log.
Even more surprisingly, when I manually edit the URL when at the WAYF server, and switch from Artifact profile to POST profile, I don't get this failure, but I don't get any attributes at all. (In the previous case, if a session is established, I have all attributes there). Strange: authentication succeeds, but all attributes are rejected - even though in the POST profile, everything is sent in a single signed assertion.
Finally, more surprise, in each case, I'm so far redirected to the registered SP home page, but not to the page where I wanted to go.
I thought about the fact that I'm accessing the SP just by the short name "idp-test" and the server does not search "canterbury.ac.nz"? It however can resolve "idp-test" locally.
When I access the server by it's canonical name, these oddities do not kick in - so I'd better try redirect the URL already at Apache level.
- Solution attempt 2: Apache redirects based on the Rewrite Engine - as documented in the Apache URL Rewriting Guide.
Put the following inside <VirtualHost 132.181.4.4:80>:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^idp-test\.canterbury\.ac\.nz [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://idp-test.canterbury.ac.nz/$1 [L,R]
This works to redirect http requests to port 80 - how comes it works even for requests which are immediately redirected to the WAYF server (to go to IdP) by the Shibboleth module? The consumer service URL at the WAYF server already has the canonical hostname.
It however does not work for requests directed to the application-level WAYF redirector:
https://idp-test/Shibboleth.sso/WAYF/level-1.federation.org.au?target=http://idp-test/secure/
still asks for "idp-test/Shibboleth.sso" - which is still broken.
Surprisingly, expanding the hostname in the target URL parameter to the canonical hostname:
https://idp-test/Shibboleth.sso/WAYF/level-1.federation.org.au?target=http://idp-test.canterbury.ac.nz/secure/
works and access the consumer service via the canonical hostname.
It appears that we cannot redirect all wrong ways of accessing the SP, but we can redirect all ways of entering the SP to the canonical hostname, and this should assure the Shibboleth login URLs generated when accessing the host this way will always use the canonical hostname.
Let us also add the following to <VirtualHost 132.181.4.4:443> in shib-vhosts.conf:
RewriteEngine On
RewriteCond %{HTTP_HOST} !^idp-test\.canterbury\.ac\.nz [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) https://idp-test.canterbury.ac.nz/$1 [L,R]
For a lazy-session SP, this redirects all entry URLs to the canonical name, and the server will then always construct login URLs via the application-level WAYF redirector with the canonical hostname.
The above solution, together with UseCanonicalName On, works also when a Shibboleth-protected URL requiring a session is accessed via an incorrect hostname - the RewriteEngine steps in before the access-control module, and the URL redirected to the WAYF server already uses the canonical hostname of the SP.
[edit] Adding a new attribute
To add a new attribute:
- define it in /usr/local/shibboleth-idp/etc/resolver.ldap.xml
<SimpleAttributeDefinition id="urn:mace:canterbury.ac.nz:attribute:ucdeptcode" sourceName="ucdeptcode">
<DataConnectorDependency requires="directory"/>
</SimpleAttributeDefinition>
- to make it visible in Autograph, add it to /usr/local/shibboleth-autograph/connectorConfigs/AttributeInfoPointData.xml
<Attribute id="urn:mace:canterbury.ac.nz:attribute:ucdeptcode" type="string">
<FriendlyName lang="en">UC Dept Code</FriendlyName>
<Description lang="en">UC department</Description>
</Attribute>
- To allow Autograph to store user-customized values for editable attributes, configure write-access to the LDAP server in /usr/local/shibboleth-autograph/connectorConfigs/AttributeWriterImplConf.config.xml
[edit] Adding a static attribute
Warning: this breaks AutoGraph. AutoGraph apparently cannot handle StaticDataConnector attributes. You need to get an updated shib-java.jar from Stuart Allen and install it into /var/lib/tomcat5/webapps/Autograph/WEB-INF/lib.
Following https://wiki.shibboleth.net/confluence/display/SHIB/StaticDataConnector, add the following into resolver.ldap.xml:
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:o">
<DataConnectorDependency requires="staticAttributesConnector"/>
</SimpleAttributeDefinition>
<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:c">
<DataConnectorDependency requires="staticAttributesConnector"/>
</SimpleAttributeDefinition>
<StaticDataConnector id="staticAttributesConnector">
<Attribute name="o">
<Value>University of Canterbury</Value>
</Attribute>
<Attribute name="c">
<Value>NZ</Value>
</Attribute>
</StaticDataConnector>
And the following into /usr/local/shibboleth-autograph/connectorConfigs/AttributeInfoPointData.xml:
<Attribute id="urn:mace:dir:attribute-def:o" type="string">
<FriendlyName lang="en">organization</FriendlyName>
<Description lang="en">no description</Description>
</Attribute>
<Attribute id="urn:mace:dir:attribute-def:c" type="string">
<FriendlyName lang="en">country</FriendlyName>
<Description lang="en">no description</Description>
</Attribute>
[edit] Adding a Scriptlet Attribute Definition
The ScriptletAttributeDefinition element allows to use arbitrary Java code to construct the value of an attribute from other attributes. This supersedes the problematic Crosswalk IF function, and provides a much more flexible solution. However, same as for the StaticDataConnector, Autograph cannot handle a ScripletAttributeDefinition straight from the box, and a similar change to shib-java.jar may be necessary.
The internet2 page documents pretty clearly what can be used in the scriptlet. Looking at further documentation, from
edu.internet2.middleware.shibboleth.aa.attrresolv.Dependencies depencencies;
I can get:
public Attributes getConnectorResolution(String id);
public ResolverAttribute getAttributeResolution(String id);
Attributes I'd use will be accessed as edu.internet2.middleware.shibboleth.aa.attrresolv.ResolverAttribute
public void addValue(Object value);
public Iterator getValues();
Finally, a small scriptlet using the value of an attribute to compute a new attribute:
<ScriptletAttributeDefinition id="urn:mace:dir:attribute-def:carLicense">
<DataConnectorDependency requires="directory"/>
<AttributeDependency requires="urn:mace:dir:attribute-def:givenName"/>
<Scriptlet><![CDATA[
ResolverAttribute givenNameAttr = dependencies.getAttributeResolution("urn:mace:dir:attribute-def:givenName");
String givenNameStr = null;
if (givenNameAttr != null) {
Iterator i = givenNameAttr.getValues();
if (i.hasNext()) { givenNameStr = (String)i.next(); };
};
if (givenNameStr != null ) {
resolverAttribute.addValue("myCar:" + givenNameStr);
};
]]>
</Scriptlet>
</ScriptletAttributeDefinition>
[edit] Terminating MediaWiki sessions when a Shibboleth session expires
With the ShibAuthPlugin, and particularly with how it integrates with the MediaWiki AccessControl extension, I've experienced the following issue:
When a Shibboleth sesison timed out, the PHP/MW session still stayed on, and the user would be permitted to access protected pages, even though Shibboleth and the ShibAuthPlugin thought there was no session anymore. To edit pages, the user would be asked to login again, but the persisting PHP session would let the user through to restricted pages.
It's not really a security hole - it would only let through users who had previously established a valid session - but I still thought it would deserve some attention.
The following modification to ShibAuthPlugin fixes it: create a ShibForceLogout function that foces the PHP MW session to log the user out, when there's no Shibboleth session. This function then get's called via a hook - and the hook is used only when there's no Shibboleth session.
--- ShibAuthPlugin.php-orig-2008-10-08 2008-10-08 13:03:00.000000000 +1300
+++ ShibAuthPlugin.php 2008-10-08 12:59:00.000000000 +1300
@@ -278,6 +278,17 @@
}
/*
+ * Vladimir Mencl 2008-10-08
+ * If there is no Shib Session, force a logout on the MW session
+ */
+function ShibForceLogout(&$user)
+{
+ global $shib_UN;
+ if (($user != null) && ($user->isLoggedIn()) && ($shib_UN == null)) $user->logout();
+ return true;
+}
+
+/*
* End of AuthPlugin Code, beginning of hook code and auth functions
*/
function SetupShibAuth()
@@ -304,6 +315,8 @@
}
else
{
+ $wgHooks['AutoAuthenticate'][] = 'ShibForceLogout'; /* Hook for force a logout when there's no Shib session */
+
$wgHooks['PersonalUrls'][] = 'SSOLinkAdd';
if(isset($_GET['action']))
{
[edit] SLCS client
Using the SLCS client for the ARCS test SLCS server - https://slcstest.arcs.org.au/SLCS/login
- Some SLCS client libraries are available at https://projects.arcs.org.au/trac/slcs-client/
- But the real thing is the command-line client at
https://projects.arcs.org.au/trac/slcs-client/wiki/CommandLineClient
Do the steps as recommended:
svn co https://projects.arcs.org.au/svn/slcs-client/trunk/org.glite.slcs.ui svn co https://projects.arcs.org.au/svn/slcs-client/trunk/org.glite.slcs.common cd org.glite.slcs.common ant repository ant cd .. cd org.glite.slcs.ui ant repository ant
- And then untar glite-slcs-ui-1.3.2-jdk1.6.tar.gz somewhere.
- Edit </tt>etc/glite-slcs-ui/slcs-init.xml</tt> and change the absolute path to <TrustStoreFile> to where the SLCS client is installed.
- Now run
./slcs-init -i canterbury.ac.nz -u vme28
[edit] Minor bits of Shibboleth knowledge
A few questions I've asked Bruc Liong at eResearch2008:
- POST/Artifact profile
- => Artifact profile preferred if firewall permits
- Switching can be done by setting the isDefault="true" attribute in SP's shibboleth.xml:
<md:AssertionConsumerService Location="/SAML/POST" index="2" isDefault="true" Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>
- Switching can be done by setting the isDefault="true" attribute in SP's shibboleth.xml:
- => Artifact profile preferred if firewall permits
- => POST profile should use encryption
- I wonder how the client would know SP's pub key and how it would be turned on => documented at Internet2 Shibboleth space
- => POST profile will need to resolve attributes via AA if attributes not pushed (config in idp.xml), see https://wiki.shibboleth.net/confluence/display/SHIB/AlternateProfiles
- => POST profile should use encryption
- Redundancy in IdP:
- => yes, there is a solution (via a shared DB of issued tokens)
- => would need tomcat loadbalancer
- => would still have a single point of failure
- Forms vs. https for SSO authn:
- => https/apache preferred: simpler to administer, simpler with tools
- => use forms only if pressed by institution for branding
- An IdP can have multiple entityIds, each used for a different set of hosts (e.g., by federation membership). This is configured by using multiple <RelyingParty/> elements in idp.xml. See https://wiki.shibboleth.net/confluence/display/SHIB/IdPRelyingConfig
- The format of a SAML Artifact is defined by SAML Bindings and Profiles as Base64 encoding of the following sequence:
- TypeCode: 0x0001
- SourceID: 20 byte sequence, SHA1 hash of entityId of the IdP
- AssertionHandle: 20-byte sequence, should be unfeasible to predict
[edit] Forcing Attribute-Push for a single SP
The above can be combined into a RelyingParty configuration setting the forceAttributePush attribute:
<RelyingParty name="urn:mace:federation.org.au:testfed:slcs1.arcs.org.au" forceAttributePush="true" />
[edit] Configuring Admin Contact for Error Messages
When the IdP encounters an error and must display an error message, it would include the email address of the system administrator. This is configured by editing /var/lib/tomcat5/webapps/shibboleth-idp/IdPError.jsp (or ./webApplication/IdPError.jsp in the source tree).
Replace the text root@localhost (and the corresponding link) with the correct address.
[edit] Generating a self-signed certificate
If one needs a Shibboleth 2.0 style self-signed certificate on a Shibboleth 1.3 system (such as to register with resource registry), this is the way to generate it:
- create OpenSSL configuration file cert.conf with the following contents (replace idp.example.org with your hostname)
# OpenSSL configuration file for creating sp-cert.pem [req] prompt=no default_bits=2048 encrypt_key=no default_md=sha1 distinguished_name=dn # PrintableStrings only string_mask=MASK:0002 x509_extensions=ext [dn] CN=idp.example.org [ext] subjectAltName=DNS:idp.example.org,URI:https://idp.example.org/idp/shibboleth subjectKeyIdentifier=hash
- generate the certificate with
openssl req -x509 -newkey rsa:2048 -nodes -out `hostname`-self-cert.pem -keyout `hostname`-self-key.pem -config cert.conf
[edit] AAF Pilot Entity Group Names
- "aaf.edu.au" (no URN prefix) for Pilot Test
- "urn:mace:aaf.edu.au:AAFProduction" for Pilot production
[edit] Shibboleth 2.0 policy filter
- Shibboleth 2.0 policy filter basic:OR does not work with just one operand.
- Either use the same operand twice :-), or use the operand at top-level directly - like:
<PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://manager.aaf.edu.au/shibboleth" />
- Either use the same operand twice :-), or use the operand at top-level directly - like:
[edit] IdP and SP metadata URLs
- The IdP metadata can be retrieved from: https://idp.example.org/idp/profile/Metadata/SAML
- The SP metadata can be retrieved from: https://sp.example.org/Shibboleth.sso/Metadata
[edit] Getting raw assertions
- Add exportAssertion="true" into the <Path> element in the <RequestMapper> in /etc/shibboleth/shibboleth2.xml
- Alternatively, add the following Apache directive into /etc/httpd/conf.d/shib.conf:
ShibRequestSetting exportAssertion true
- Access /secure on the host and dump the Apache environment - e.g., with phpinfo()
- The Apache environemnt now contains entries like:
Shib-Assertion-01 http://localhost/Shibboleth.sso/GetAssertion?key=_cbf2e5ecb17c7f1a4a56e7ebb06122ba&ID=_fb3417ef0316a2beb53ccd6c131541ec Shib-Assertion-Count 01
- Log into the host and with a locally running browser (links), access the URL - you may have to change http to https. This will give you the XML raw assertion.
- See https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAssertionExport for more information
[edit] Configuring multiple DS initiators with ShibSP 2.4
Shib SP 2.4 introduces a single <SSO> element that points to ONE DS.
To experiment with different Discovery Services and have explicit session initiator URLs pointing to the different DS instances, add the <SessionInitiator> element (or more of them) into shibboleth2.xml after the <SSO> and <Logout> elements.
Example:
<SSO
discoveryProtocol="SAMLDS" discoveryURL="https://directory.test.tuakiri.ac.nz/ds/DS">
SAML2 SAML1
</SSO>
<!-- taken out: entityID="https://idp.example.org/shibboleth" -->
<!-- SAML and local-only logout. -->
<Logout>SAML2 Local</Logout>
<!-- manually defined additional DS initiators - without isDefault and with custom IDs and Locations -->
<SessionInitiator type="Chaining" Location="/DS-AAF-TEST" id="DS-AAF-TEST" relayState="cookie">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
<SessionInitiator type="SAMLDS" URL="https://ds.test.aaf.edu.au/discovery/DS"/>
</SessionInitiator>
<SessionInitiator type="Chaining" Location="/DS-Tuakiri-TEST" id="DS-Tuakiri-TEST" relayState="cookie">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
<SessionInitiator type="SAMLDS" URL="https://directory.test.tuakiri.ac.nz/ds/DS"/>
</SessionInitiator>
<SessionInitiator type="Chaining" Location="/DS-Tuakiri-DEV" id="DS-Tuakiri-DEV" relayState="cookie">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
<SessionInitiator type="SAMLDS" URL="https://directory.test.tuakiri.ac.nz/ds-DEV/DS"/>
</SessionInitiator>
<SessionInitiator type="Chaining" Location="/DS-Tuakiri" id="DS-Tuakiri" relayState="cookie">
<SessionInitiator type="SAML2" acsIndex="1" template="bindingTemplate.html"/>
<SessionInitiator type="Shib1" acsIndex="5"/>
<SessionInitiator type="SAMLDS" URL="https://ds.tuakiri.ac.nz/ds/DS"/>
</SessionInitiator>
Then access the URLs via /Shibboleth.sso on the HTTPS port: https://gridgwtest.canterbury.ac.nz/Shibboleth.sso/DS-Tuakiri-TEST
- Important: for these new DS endpoints to work with the Shibboleth project DS implementation, it is necessary to register all of these endpoints into the metadata loaded by the DS - registering multiple Discovery Response Service endpoints.
- Example:
<EntityDescriptor entityID="https://gridgwtest.canterbury.ac.nz/shibboleth">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
<Extensions>
<dsr:DiscoveryResponse xmlns:dsr="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://gridgwtest.canterbury.ac.nz/Shibboleth.sso/DS-Tuakiri" index="4" isDefault="false"/>
<dsr:DiscoveryResponse xmlns:dsr="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://gridgwtest.canterbury.ac.nz/Shibboleth.sso/DS-Tuakiri-DEV" index="3" isDefault="false"/>
<dsr:DiscoveryResponse xmlns:dsr="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://gridgwtest.canterbury.ac.nz/Shibboleth.sso/Login" index="0" isDefault="true"/>
<dsr:DiscoveryResponse xmlns:dsr="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://gridgwtest.canterbury.ac.nz/Shibboleth.sso/DS-AAF-TEST" index="1" isDefault="false"/>
<dsr:DiscoveryResponse xmlns:dsr="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://gridgwtest.canterbury.ac.nz/Shibboleth.sso/DS-Tuakiri-TEST" index="2" isDefault="false"/>
</Extensions>
[edit] Tweaking the ShibSP SessionInitiator with query parameters
- To force login through the default SessionInitiator going directly to an IdP, pass the IdP entityID in the *entityID* query parameter:
https://www.etv.org.nz/Shibboleth.sso/DS?entityID=https://idp.canterbury.ac.nz/idp/shibboleth&target=http://www.etv.org.nz/shib/
- To use a different DS than the one set in the SessionInitiator configuration, pass the DS URL in the *discoveryURL* query parameter:
https://www.etv.org.nz/Shibboleth.sso/DS?discoveryURL=https://directory.tuakiri.ac.nz/ds/DS&target=http://www.etv.org.nz/shib/
[edit] Accessing HTTPS URLs from a Shibboleth IdP configuration
When running a Shibboleth IdP on OpenJDK-1.6.0-Java, care must be taken to make sure all HTTPS servers are properly configured. OpenJDK's SSL implementation is pickier then OpenSSL or Sun Java's SSL and rejects servers that are offering extra certificates in the certificate chain - even if the chain also includes all certificates needed to establish the trust.
[edit] Shib Logout
- SP configuration page: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPServiceLogout
- Application-level <Notify> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPNotify
- IdP logout - why not implemented https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues
[edit] Generating a shared token value
Manually:openssl rand -base64 20 | tr "/+=" "_\- "
[edit] Shibbolized systems
Systems that support Shibboleth login - AFAIK
- See the completely list at https://wiki.shibboleth.net/confluence/display/SHIB2/ShibEnabled
So far:
- MediaWiki
- Confluence Wiki
- JIRA
- GridSphere
- Blackboard
- Moodle
- Elsevier ScienceDirect
- Microsoft Dreamspark
- Grid: SLCS server
- Grid: Hermes: Data storage
- Library chat helpdesk
- SubEtha: Mailing lists
- OpenMeeting: video conferencing
