MetadataResolverService Initial load failed?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

MetadataResolverService Initial load failed?

Scott Gilbert
Installing shibboleth idp 3.4.6 and getting the idp-process.log error on start up below. I have reviewed the documentation and none of the more obvious solutions work. I must be missing something.



2019-11-26 14:07:11,763 -  - INFO [net.shibboleth.utilities.java.support.service.AbstractReloadableService:173] - Service 'shibboleth.MetadataResolverService': Performing initial load
2019-11-26 14:07:11,764 -  - INFO [net.shibboleth.utilities.java.support.service.AbstractReloadableService:258] - Service 'shibboleth.MetadataResolverService': Reloading service configuration
2019-11-26 14:07:11,766 -  - INFO [net.shibboleth.ext.spring.util.SchemaTypeAwareXMLBeanDefinitionReader:317] - Loading XML bean definitions from file [/opt/shibboleth-idp/conf/metadata-providers.xml]
2019-11-26 14:07:11,844 -  - INFO [net.shibboleth.ext.spring.util.SchemaTypeAwareXMLBeanDefinitionReader:317] - Loading XML bean definitions from file [/opt/shibboleth-idp/system/conf/metadata-providers-system.xml]
2019-11-26 14:07:11,849 -  - INFO [net.shibboleth.ext.spring.context.FilesystemGenericApplicationContext:583] - Refreshing shibboleth.MetadataResolverService: startup date [Tue Nov 26 14:07:11 PST 2019]; parent: Root WebApplicationContext
2019-11-26 14:07:11,860 -  - WARN [net.shibboleth.ext.spring.context.FilesystemGenericApplicationContext:551] - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.opensaml.saml.metadata.resolver.filter.impl.SignatureValidationFilter#0': Cannot create inner bean '(inner bean)#2fdeaa3c' of type [org.opensaml.xmlsec.signature.support.impl.ExplicitKeySignatureTrustEngine] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2fdeaa3c': Cannot create inner bean '(inner bean)#2c4a78dd' of type [org.opensaml.security.credential.impl.StaticCredentialResolver] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2c4a78dd': Cannot create inner bean '(inner bean)#5ff6431a' of type [net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#5ff6431a': Invocation of init method failed; nested exception is org.cryptacular.StreamException: IO error
2019-11-26 14:07:11,866 -  - ERROR [net.shibboleth.utilities.java.support.service.AbstractReloadableService:182] - Service 'shibboleth.MetadataResolverService': Initial load failed
net.shibboleth.utilities.java.support.service.ServiceException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.opensaml.saml.metadata.resolver.filter.impl.SignatureValidationFilter#0': Cannot create inner bean '(inner bean)#2fdeaa3c' of type [org.opensaml.xmlsec.signature.support.impl.ExplicitKeySignatureTrustEngine] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2fdeaa3c': Cannot create inner bean '(inner bean)#2c4a78dd' of type [org.opensaml.security.credential.impl.StaticCredentialResolver] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2c4a78dd': Cannot create inner bean '(inner bean)#5ff6431a' of type [net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#5ff6431a': Invocation of init method failed; nested exception is org.cryptacular.StreamException: IO error
at net.shibboleth.ext.spring.service.ReloadableSpringService.doReload(ReloadableSpringService.java:377)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.opensaml.saml.metadata.resolver.filter.impl.SignatureValidationFilter#0': Cannot create inner bean '(inner bean)#2fdeaa3c' of type [org.opensaml.xmlsec.signature.support.impl.ExplicitKeySignatureTrustEngine] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2fdeaa3c': Cannot create inner bean '(inner bean)#2c4a78dd' of type [org.opensaml.security.credential.impl.StaticCredentialResolver] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2c4a78dd': Cannot create inner bean '(inner bean)#5ff6431a' of type [net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#5ff6431a': Invocation of init method failed; nested exception is org.cryptacular.StreamException: IO error
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2fdeaa3c': Cannot create inner bean '(inner bean)#2c4a78dd' of type [org.opensaml.security.credential.impl.StaticCredentialResolver] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2c4a78dd': Cannot create inner bean '(inner bean)#5ff6431a' of type [net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#5ff6431a': Invocation of init method failed; nested exception is org.cryptacular.StreamException: IO error
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#2c4a78dd': Cannot create inner bean '(inner bean)#5ff6431a' of type [net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean] while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#5ff6431a': Invocation of init method failed; nested exception is org.cryptacular.StreamException: IO error
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:313)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name '(inner bean)#5ff6431a': Invocation of init method failed; nested exception is org.cryptacular.StreamException: IO error
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1631)
Caused by: org.cryptacular.StreamException: IO error
at org.cryptacular.util.CertUtil.readCertificateChain(CertUtil.java:328)
Caused by: java.io.IOException: Incomplete data
at sun.security.provider.X509Factory.readOneBlock(X509Factory.java:612)
2019-11-26 14:07:11,867 -  - ERROR [net.shibboleth.utilities.java.support.service.AbstractReloadableService:186] - Service 'shibboleth.MetadataResolverService': No further attempts will be made to reload


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Christopher Bongaarts
Check the contents and permissions of your InCommon metadata validation
certificate...

On 11/26/2019 4:28 PM, Scott Gilbert wrote:

> Caused by: org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name '(inner bean)#5ff6431a': Invocation of
> init method failed; nested exception is
> org.cryptacular.StreamException: IO error
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1631)
> Caused by: org.cryptacular.StreamException: IO error
> at org.cryptacular.util.CertUtil.readCertificateChain(CertUtil.java:328)
> Caused by: java.io.IOException: Incomplete data
> at sun.security.provider.X509Factory.readOneBlock(X509Factory.java:612)
> 2019-11-26 14:07:11,867 -  - ERROR
> [net.shibboleth.utilities.java.support.service.AbstractReloadableService:186]
> - Service 'shibboleth.MetadataResolverService': No further attempts
> will be made to reload

--
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Scott Gilbert
Thanks for the reply.

So this metadata provider statement is not sufficient

    <MetadataProvider id="INCOMMON" xsi:type="FileBackedHTTPMetadataProvider"
    metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFile="%{idp.home}/metadata/incommon-metadata.xml">

as I recall there is some form of verification, so as not to spoof, it may be in the incommon docs.

Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Tue, Nov 26, 2019 at 2:44 PM Christopher Bongaarts <[hidden email]> wrote:
Check the contents and permissions of your InCommon metadata validation
certificate...

On 11/26/2019 4:28 PM, Scott Gilbert wrote:
> Caused by: org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name '(inner bean)#5ff6431a': Invocation of
> init method failed; nested exception is
> org.cryptacular.StreamException: IO error
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1631)
> Caused by: org.cryptacular.StreamException: IO error
> at org.cryptacular.util.CertUtil.readCertificateChain(CertUtil.java:328)
> Caused by: java.io.IOException: Incomplete data
> at sun.security.provider.X509Factory.readOneBlock(X509Factory.java:612)
> 2019-11-26 14:07:11,867 -  - ERROR
> [net.shibboleth.utilities.java.support.service.AbstractReloadableService:186]
> - Service 'shibboleth.MetadataResolverService': No further attempts
> will be made to reload

--
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Christopher Bongaarts

Within that <MetadataProvider> element you'll find a nested element like this:

      <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
              certificateFile="%{idp.home}/credentials/incommon.pem" />

It's having trouble loading that certificateFile.

On 11/26/2019 5:02 PM, Scott Gilbert wrote:
Thanks for the reply.

So this metadata provider statement is not sufficient

    <MetadataProvider id="INCOMMON" xsi:type="FileBackedHTTPMetadataProvider"
    metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFile="%{idp.home}/metadata/incommon-metadata.xml">

as I recall there is some form of verification, so as not to spoof, it may be in the incommon docs.

Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Tue, Nov 26, 2019 at 2:44 PM Christopher Bongaarts <[hidden email]> wrote:
Check the contents and permissions of your InCommon metadata validation
certificate...

On 11/26/2019 4:28 PM, Scott Gilbert wrote:
> Caused by: org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name '(inner bean)#5ff6431a': Invocation of
> init method failed; nested exception is
> org.cryptacular.StreamException: IO error
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1631)
> Caused by: org.cryptacular.StreamException: IO error
> at org.cryptacular.util.CertUtil.readCertificateChain(CertUtil.java:328)
> Caused by: java.io.IOException: Incomplete data
> at sun.security.provider.X509Factory.readOneBlock(X509Factory.java:612)
> 2019-11-26 14:07:11,867 -  - ERROR
> [net.shibboleth.utilities.java.support.service.AbstractReloadableService:186]
> - Service 'shibboleth.MetadataResolverService': No further attempts
> will be made to reload

--
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

-- 
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Scott Gilbert
Still getting the same error message. Below is my current incommon config. 

    <MetadataProvider id="INCOMMON" xsi:type="FileBackedHTTPMetadataProvider"
        metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFile="%{idp.home}/metadata/incommon-metadata.xml">
      <MetadataFilter xsi:type="SignatureValidation" certificateFile="%{idp.home}/credentials/inc-md-cert.pem" />
    </MetadataProvider>

Do I need to state this?
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P30D"/>

I have enough memory allocated 
Environment="CATALINA_OPTS=-Xms512M -Xmx2048M -server -XX:+UseG1GC"


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Tue, Nov 26, 2019 at 3:16 PM Christopher Bongaarts <[hidden email]> wrote:

Within that <MetadataProvider> element you'll find a nested element like this:

      <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
              certificateFile="%{idp.home}/credentials/incommon.pem" />

It's having trouble loading that certificateFile.

On 11/26/2019 5:02 PM, Scott Gilbert wrote:
Thanks for the reply.

So this metadata provider statement is not sufficient

    <MetadataProvider id="INCOMMON" xsi:type="FileBackedHTTPMetadataProvider"
    metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFile="%{idp.home}/metadata/incommon-metadata.xml">

as I recall there is some form of verification, so as not to spoof, it may be in the incommon docs.

Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Tue, Nov 26, 2019 at 2:44 PM Christopher Bongaarts <[hidden email]> wrote:
Check the contents and permissions of your InCommon metadata validation
certificate...

On 11/26/2019 4:28 PM, Scott Gilbert wrote:
> Caused by: org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name '(inner bean)#5ff6431a': Invocation of
> init method failed; nested exception is
> org.cryptacular.StreamException: IO error
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1631)
> Caused by: org.cryptacular.StreamException: IO error
> at org.cryptacular.util.CertUtil.readCertificateChain(CertUtil.java:328)
> Caused by: java.io.IOException: Incomplete data
> at sun.security.provider.X509Factory.readOneBlock(X509Factory.java:612)
> 2019-11-26 14:07:11,867 -  - ERROR
> [net.shibboleth.utilities.java.support.service.AbstractReloadableService:186]
> - Service 'shibboleth.MetadataResolverService': No further attempts
> will be made to reload

--
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

-- 
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Scott Gilbert
To back up a bit, this is a new tomcat server and shibboleth idp 3.4.6. I have copied the data over from an existing (working) shibboleth idp 3.2.1. The data would include idp.property settings, metadata, and credentials. The entire credentials directory. I am concerned copying the cert files over may be the issue, but tomcat and shibboleth are set up properly to use them. My thinking now is that copying over the conf directory metadata is ok with a few minor tweaks, but I need to create a whole suite of new certs for this new server.

 Service 'shibboleth.MetadataResolverService': Initial load failed
net.shibboleth.utilities.java.support.service.ServiceException: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.opensaml.saml.metadata.resolver.filter.impl.SignatureValidationFilter#0': Cannot create inner bean '(inner bean)#3e38a99c' of type [org.opensaml.xmlsec.signature.support.impl.ExplicitKeySignatureTrustEngine]

The entire error message are in my first post.


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Wed, Nov 27, 2019 at 10:04 AM Scott Gilbert <[hidden email]> wrote:
Still getting the same error message. Below is my current incommon config. 

    <MetadataProvider id="INCOMMON" xsi:type="FileBackedHTTPMetadataProvider"
        metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFile="%{idp.home}/metadata/incommon-metadata.xml">
      <MetadataFilter xsi:type="SignatureValidation" certificateFile="%{idp.home}/credentials/inc-md-cert.pem" />
    </MetadataProvider>

Do I need to state this?
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P30D"/>

I have enough memory allocated 
Environment="CATALINA_OPTS=-Xms512M -Xmx2048M -server -XX:+UseG1GC"


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Tue, Nov 26, 2019 at 3:16 PM Christopher Bongaarts <[hidden email]> wrote:

Within that <MetadataProvider> element you'll find a nested element like this:

      <MetadataFilter xsi:type="SignatureValidation" requireSignedRoot="true"
              certificateFile="%{idp.home}/credentials/incommon.pem" />

It's having trouble loading that certificateFile.

On 11/26/2019 5:02 PM, Scott Gilbert wrote:
Thanks for the reply.

So this metadata provider statement is not sufficient

    <MetadataProvider id="INCOMMON" xsi:type="FileBackedHTTPMetadataProvider"
    metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml" backingFile="%{idp.home}/metadata/incommon-metadata.xml">

as I recall there is some form of verification, so as not to spoof, it may be in the incommon docs.

Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Tue, Nov 26, 2019 at 2:44 PM Christopher Bongaarts <[hidden email]> wrote:
Check the contents and permissions of your InCommon metadata validation
certificate...

On 11/26/2019 4:28 PM, Scott Gilbert wrote:
> Caused by: org.springframework.beans.factory.BeanCreationException:
> Error creating bean with name '(inner bean)#5ff6431a': Invocation of
> init method failed; nested exception is
> org.cryptacular.StreamException: IO error
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1631)
> Caused by: org.cryptacular.StreamException: IO error
> at org.cryptacular.util.CertUtil.readCertificateChain(CertUtil.java:328)
> Caused by: java.io.IOException: Incomplete data
> at sun.security.provider.X509Factory.readOneBlock(X509Factory.java:612)
> 2019-11-26 14:07:11,867 -  - ERROR
> [net.shibboleth.utilities.java.support.service.AbstractReloadableService:186]
> - Service 'shibboleth.MetadataResolverService': No further attempts
> will be made to reload

--
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

-- 
%%  Christopher A. Bongaarts   %%  [hidden email]          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Cantor, Scott E.
On 11/27/19, 1:36 PM, "users on behalf of Scott Gilbert" <[hidden email] on behalf of [hidden email]> wrote:

> To back up a bit, this is a new tomcat server and shibboleth idp 3.4.6. I have copied the data over from an existing
> (working) shibboleth idp 3.2.1. The data would include idp.property settings, metadata, and credentials. The entire
> credentials directory.

And the InCommon verification key file isn't the same. Or the original isn't/wasn't working to start with. Or there's a Java difference of an unknown nature.
 
-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Scott Gilbert
The previous sysadmin got the shib service to run without the incommon validation cert, and just the url for the incommon metadata is in metadata-providers.xml. I was suprised to discover this as I diagnosed this error.

shib 3.2.1 working service
tomcat-8.0.24
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

New server shib 3.4.6
tomcat-9.0.26
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Wed, Nov 27, 2019 at 10:51 AM Cantor, Scott <[hidden email]> wrote:
On 11/27/19, 1:36 PM, "users on behalf of Scott Gilbert" <[hidden email] on behalf of [hidden email]> wrote:

> To back up a bit, this is a new tomcat server and shibboleth idp 3.4.6. I have copied the data over from an existing
> (working) shibboleth idp 3.2.1. The data would include idp.property settings, metadata, and credentials. The entire
> credentials directory.

And the InCommon verification key file isn't the same. Or the original isn't/wasn't working to start with. Or there's a Java difference of an unknown nature.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Scott Gilbert
The SignatureValidation issue is resolved, no error. I left out the validUntil.

    <MetadataProvider id="incommon"
                      xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/incommon-metadata.xml"
                      metadataURL="http://md.incommon.org/InCommon/InCommon-metadata.xml">
       
        <MetadataFilter xsi:type="SignatureValidation" certificateFile="%{idp.home}/credentials/inc-md-cert.pem" />
        <MetadataFilter xsi:type="RequiredValidUntil" maxValidityInterval="P30D"/>
    </MetadataProvider>

But as par for the course I have another error and its for the very end of the metadata-providers.xml file. Its well formed and valid. I am not sure what to check.

2019-11-27 14:39:58,147 -  - INFO [net.shibboleth.utilities.java.support.service.AbstractReloadableService:173] - Service 'shibboleth.MetadataResolverService': Performing initial load
2019-11-27 14:39:58,147 -  - INFO [net.shibboleth.utilities.java.support.service.AbstractReloadableService:258] - Service 'shibboleth.MetadataResolverService': Reloading service configuration
2019-11-27 14:39:58,149 -  - INFO [net.shibboleth.ext.spring.util.SchemaTypeAwareXMLBeanDefinitionReader:317] - Loading XML bean definitions from file [/opt/shibboleth-idp/conf/metadata-providers.xml]
2019-11-27 14:39:58,208 -  - ERROR [net.shibboleth.utilities.java.support.service.AbstractReloadableService:182] - Service 'shibboleth.MetadataResolverService': Initial load failed
net.shibboleth.utilities.java.support.service.ServiceException: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 332 in XML document from file [/opt/shibboleth-idp/conf/metadata-providers.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 332; columnNumber: 20; cvc-complex-type.2.3: Element 'MetadataProvider' cannot have character [children], because the type's content type is element-only.
at net.shibboleth.ext.spring.service.ReloadableSpringService.doReload(ReloadableSpringService.java:377)
Caused by: org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 332 in XML document from file [/opt/shibboleth-idp/conf/metadata-providers.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 332; columnNumber: 20; cvc-complex-type.2.3: Element 'MetadataProvider' cannot have character [children], because the type's content type is element-only.
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:399)
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.3: Element 'MetadataProvider' cannot have character [children], because the type's content type is element-only.
at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203)


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Wed, Nov 27, 2019 at 11:39 AM Scott Gilbert <[hidden email]> wrote:
The previous sysadmin got the shib service to run without the incommon validation cert, and just the url for the incommon metadata is in metadata-providers.xml. I was suprised to discover this as I diagnosed this error.

shib 3.2.1 working service
tomcat-8.0.24
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

New server shib 3.4.6
tomcat-9.0.26
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Wed, Nov 27, 2019 at 10:51 AM Cantor, Scott <[hidden email]> wrote:
On 11/27/19, 1:36 PM, "users on behalf of Scott Gilbert" <[hidden email] on behalf of [hidden email]> wrote:

> To back up a bit, this is a new tomcat server and shibboleth idp 3.4.6. I have copied the data over from an existing
> (working) shibboleth idp 3.2.1. The data would include idp.property settings, metadata, and credentials. The entire
> credentials directory.

And the InCommon verification key file isn't the same. Or the original isn't/wasn't working to start with. Or there's a Java difference of an unknown nature.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Peter Schober
* Scott Gilbert <[hidden email]> [2019-11-28 00:50]:
> But as par for the course I have another error and its for the very end of
> the metadata-providers.xml file. Its well formed and valid. I am not sure
> what to check.
>
> Line 332 in XML document from file
> [/opt/shibboleth-idp/conf/metadata-providers.xml] is invalid; nested
> exception is org.xml.sax.SAXParseException; lineNumber: 332; columnNumber:
> 20; cvc-complex-type.2.3: Element 'MetadataProvider' cannot have character
> [children], because the type's content type is element-only.

Check for spurious whitespace, other than that the error message is as
precise as theoretically possible, stating both the exact location (to
the letter) and nature of the problem.

Other than that, having a metadata-providers.xml file with 300+ lines
seems to be indicative of some deeper misunderstandings or usage
anti-patterns.
But that all pales in comparison when you've been loading InCommon
metadata for years without signature checking that all, of course.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Scott Gilbert
In reply to this post by Scott Gilbert
Thanks for the info I tend to stay away from validuntil commands in my config but this did get rid on the first metadata loading error. In general there is something missing between our current 3.2.1 idp version and 3.4.6 version in that the metadata will not load. This newest error doesnt make sense because the metadata-providers.xml is valid and well formed.


Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Thu, Nov 28, 2019 at 2:33 AM Alan Buxey <[hidden email]> wrote:
hi,

> The previous sysadmin got the shib service to run without the incommon validation cert, and just the url for the incommon metadata is in metadata-providers.xml. I was suprised to discover this as I diagnosed this error.


well, you can do that - but that breaks one of the key trust/security
principles of SAML federation , as someone could insert rogue data
onto the remote server which you then take without checking.
(this is why using just http rather than https is actually okay too -
as the check is via the signature check of the data).

likewise, you dont need to have valid period check - thats an extra
thats often added by admins on policy requirement , if you know , or
get told, that it will be refreshed every X days, then check that
(some federation metadata validity period is a year! :( )   a downside
to this check is if the federation decide to sign for a longer period
due to eg planned holiday periods....so they sign the eg 18th
December for 3 weeks to cover until they are back for new year - but
you have a 2 week check.. download data. bang. invalid. right on top
of when you want to go (but it would be working fine on 25th
because its now only 2 weeks period left....happy times . ;-)  )

your other error though - are you pulling in another metadata file
that is a single entity rather than an entity container?

alan

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: MetadataResolverService Initial load failed?

Scott Gilbert
In reply to this post by Peter Schober

Thanks Peter I will check the whitespace, forgot about that, and for your general xml guidance. I inherited this idp and once I get 3.4.6 running I plan to go back to perform some much needed clean up.

Scott Gilbert
IAM System Admin
ETS Enterprise Technology Services
University of California Santa Barbara



On Thu, Nov 28, 2019 at 2:34 AM Peter Schober <[hidden email]> wrote:
* Scott Gilbert <[hidden email]> [2019-11-28 00:50]:
> But as par for the course I have another error and its for the very end of
> the metadata-providers.xml file. Its well formed and valid. I am not sure
> what to check.
>
> Line 332 in XML document from file
> [/opt/shibboleth-idp/conf/metadata-providers.xml] is invalid; nested
> exception is org.xml.sax.SAXParseException; lineNumber: 332; columnNumber:
> 20; cvc-complex-type.2.3: Element 'MetadataProvider' cannot have character
> [children], because the type's content type is element-only.

Check for spurious whitespace, other than that the error message is as
precise as theoretically possible, stating both the exact location (to
the letter) and nature of the problem.

Other than that, having a metadata-providers.xml file with 300+ lines
seems to be indicative of some deeper misunderstandings or usage
anti-patterns.
But that all pales in comparison when you've been loading InCommon
metadata for years without signature checking that all, of course.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]