shibboleth2.4 configuration error

[Peter Schober]

* Juan Fu <jfu_gengyue at hotmail.com> [2013-11-20 21:05]:
> Our environment is J2ee. So we installed shibboleth2.4 on linux
> which is already hosting a Java/web application and followed
> http://wiki.aaf.edu.au/tech-info/identity-provider/new-idp-install-guide-2-4-0-uApprove-2-5-0#TOC-Install-packages
> to install and configure IDP

Note that when you follow someone else's documentation (instead of the
official Shibboleth documentation) you should ask /them/ (the AAF, in
this case) for support, as the Shib project doesn't have the resources
to monitor or correct or even review what other stuff might be out
there.

> 1.        I notice when I browse http://testidp.mycompany.com:8080/idp/shibboleth, I notice EntityID shown as https://testidp.mycompany.com:8080/idp/shibboleth, <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://testidp.mycompany.com/idp/profile/SAML2/POST/SLO" />, <SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="http://testidp.mycompany.com/idp/profile/Shibboleth/SSO"/>

The entityID is what you set it to. It doe snot need to and probably
should not contain port numbers, it's not a URL (or rather not used as
such), just a unique name.
Whether you have another process running on port 80 (or 443) is
immaterial for the value of the entityID.

Not so for the protocol endpoints, i.e., the other URLs you list
above. The installed guess you would be using https for all those (as
you should) and the port is not in there, which will likely cause
problems when your container running the IdP is only listening on port
8080.

> if I browse  https://testidp.mycompany.com:8080/idp/shibboleth, it
> shows certificate error and when I click continue, it shows error.

The cert error has nothing to do with Shibboleth (you'll need a
correctly configured webserver, either way) but does not surprise me
at all (often 8080 is used for plain http traffic, not TLS/SSL
protected one).
As to the "error" which is shown, should we guess at what the error
might be or do you intend to tell us?

> 2.       When I configure relying-party.xml 
> 
> a)      Add below code after </rp:DefaultRelyingParty>
> <rp:RelyingParty id="http://remote simpleSAMLphp SP IP address" 
> 
> provider="http://testidp.mycompany.com:8080/idp/shibboteth"
> 
> defaultSigningCredentialRef="IdPCredential" >
> 
> <rp: ProfileConfiguration xsi:type="saml:SAML2SSOProfile" 
> 
> encryptNameIds="never" />
> 
> </rp: RelyingParty>

None of that should be needed, so remove all of it. (encryptNameIds
defaults to never, for a long time now.)


> b)      Add <metadata:MetadataProvider id="TESTMD" xsi:type="metadata:FileBackedHTTPMetadataProvider" 
> 
> metadataURL="http://remote simplesamlphp SP IP address/simplesamlphp/www/module.php/saml/sp/metadata.php/default-sp" 
> 
> backingFile="/opt/shibboleth-idp/metadata/sp.xml" >
> 
> <metadata:MetadataFilter xsi:type="metadata:ChainingFilter">
> 
> <metadata:MetadataFilter xsi:type="metadata:RequiredValidUntil" 
> 
> maxValidityInterval="P7D" />
> 
> <metadata:MetadataFilter xsi:type="metadata:SignatureValidation" 
> 
> trustEngineRef="shibboleth.MetadataTrustEngine" 
> 
> requireSignedMetadata="true" />
> 
> <metadata:MetadataFilter xsi:type="metadata:EntityRoleWhiteList">
> 
> <metadata:RetainedRole>samlmd:SPSSODescriptor</metadata:RetainedRole>
> 
> </metadata:MetadataFilter>
> 
> </metadata:MetadataFilter>
> 
> </metadata:MetadataProvider>

While you can pull metadata dynamically from the SP this is completely
insecure (as your establishing trust in cryptographic keys and
protocol endpoints via insecure DNS lookups and insecure HTTP GET
requests).

> Sp.xml is saved from metadatURL and put under credentials directory 

You don't need to do that (the software will create a backup at the
path given in backingFile). Also putting metadata not in the metadata/
directory but the credentials/ directory does not make any sense.
Furthermore, nothing will ever look there (certainly not the IdP
software; not automatically and not based on your configuration
above).
If some documentation told you to do this, it's wrong.
If you made this up yourself, stopp guessing and read the
documentation.

> c)       Add below code for security configuration 
> 
> <security:Credential id="TESTMD" xsi:type="security:X509Filesystem">
> 
> <security:PrivateKey>/opt/shibboleth-idp/credentials/saml.key</security:PrivateKey>
> 
> <security:Certificate>/opt/shibboleth-idp/credentials/saml.crt</security:Certificate>
> 
> </security:Credential>

No idea what this means and what this is for. The IdP generates its
own keypair for use with SAML protocol messages in
/opt/shibboleth-idp/credentials/idp.key and
/opt/shibboleth-idp/credentials/idp.crt
While you may rename those files in the configuration (and in the file
system) that will not make any functional difference. If you only
rename them in the config (and not in the fileystem) things will
simply break, of course.

> 10:17:34.579 - ERROR
> [edu.internet2.middleware.shibboleth.common.config.BaseService:188]
> - Configuration was not loaded for
> shibboleth.RelyingPartyConfigurationManager service, error creating
> components.  The root cause of this error was:
> org.xml.sax.SAXParseException: Element or attribute do not match
> QName production: QName::=(NCName':')?NCName.

That could mean you failed to endorse the libraries from the IdP
distribution's endorse/ directory, which is covered in the (official)
installtion documentation.
-peter