[Shib-Users] Metadata did not include a validUntil attribute

[Will Hartung]

In my relying-party.xml I have:

    <MetadataProvider id="ShibbolethMetadata" xsi:type="ChainingMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata">
   
        <!-- Load the IdP's own metadata.  This is necessary for artifact support. -->
        <MetadataProvider id="IdPMD" xsi:type="ResourceBackedMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" >
            <MetadataResource xsi:type="resource:FilesystemResource" file="/opt/shib-idp/metadata/idp-metadata.xml" />
        </MetadataProvider>
       
        <!-- Example metadata provider. -->
        <!-- Reads metadata from a URL and store a backup copy on the file system. -->
        <!-- Validates the signature of the metadata and filters out all by SP entities in order to save memory -->
        <!-- To use: fill in 'metadataURL' and 'backingFile' properties on MetadataResource element -->
        <MetadataProvider id="URLMD" xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata"
                          metadataURL="http://ssovm/Shibboleth.sso/Metadata"
                          backingFile="/opt/shib-idp/metadata/some-metadata.xml">
            <MetadataFilter xsi:type="ChainingFilter" xmlns="urn:mace:shibboleth:2.0:metadata">
                <MetadataFilter xsi:type="RequiredValidUntil" xmlns="urn:mace:shibboleth:2.0:metadata"
                                maxValidityInterval="604800" />
<!--                <MetadataFilter xsi:type="SignatureValidation" xmlns="urn:mace:shibboleth:2.0:metadata"
                                trustEngineRef="shibboleth.MetadataTrustEngine"
                                requireSignedMetadata="true" /> -->
                <MetadataFilter xsi:type="EntityRoleWhiteList" xmlns="urn:mace:shibboleth:2.0:metadata">
                    <RetainedRole>samlmd:SPSSODescriptor</RetainedRole>
                </MetadataFilter>
            </MetadataFilter>
        </MetadataProvider>
    </MetadataProvider>

All I did was change the metadataURL to "http://ssovm/Shibboleth.sso/Metadata". I have run this URL (using curl), and it provides XML data.

I also commented out the "SignatureValidation" part as it wasn't recognizing "shibboleth.MetadataTrustEngine".

Other than that, this is the stock relying-party.xml file that ships with the IdP.

When I try to start up the IdP I get:

22:59:13.562 - ERROR [edu.internet2.middleware.shibboleth.common.config.BaseService:187] - Configuration was not loaded for shibboleth.RelyingPartyConfigurationManager service, error creating components.  The root cause of this error was: org.opensaml.saml2.metadata.provider.FilterException: Metadata did not include a validUntil attribute

Any hints?

Regards,

Will Hartung

[Nate Klingenstein]

Will,

Yeah, sorry, I forgot to mention this.  In version 2.1 of the IdP, there are MetadataFilters included that enforce signature validation and date validity.  Please comment both those out, along with the ChainingFilter, because the SP doesn't sign nor date its own metadata by default.

Thanks,

Nate.

[Will Hartung]

On Fri, Jan 30, 2009 at 3:22 PM, Nate Klingenstein <n...@internet2.edu> wrote:

Will,

Yeah, sorry, I forgot to mention this.  In version 2.1 of the IdP, there are MetadataFilters included that enforce signature validation and date validity.  Please comment both those out, along with the ChainingFilter, because the SP doesn't sign nor date its own metadata by default.

Thanks,

Nate.

Do I need to comment out the entire  Metadata Chaining filter? or of the 3 within that, which should I keep. The EntityRoleWhiteList?

Thanx!

Regards,

Will Hartung

[Nate Klingenstein]

It's simplest if you just comment out the whole thing.  The entity white role is primarily there for efficiency in loading metadata and memory management.  It'll be useful in the future, but not an issue right now.

[Will Hartung]

Thanx Nate!

I'm making progress!

Through stumbling about, I needed to tweak the IdP metadata with the correct URLs.

So, I saw it going through some aspect of the handshake.

And this is my latest.

I was never prompted with a login form or anything.



opensaml::FatalProfileException

The system encountered an error at Fri Jan 30 16:34:29 2009

To report this problem, please contact the site administrator at root@localhost.

Please include the following message in any email:

opensaml::FatalProfileException at (http://healthbridge-sso.webreachinc.com/Shibboleth.sso/SAML2/POST)

SAML response contained an error.

Error from identity provider:

    Status: urn:oasis:names:tc:SAML:2.0:status:Responder
    Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed

[Nate Klingenstein]

Will,

You're getting very close.  I assume it never asked you to authenticate.  You need to configure the IdP to request authentication in some form.  By default, it uses REMOTE_USER based authentication.  Try looking at the documentation here, and let me know if you have troubles:

https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn

Take care,

Nate.

[Will Hartung]

On Fri, Jan 30, 2009 at 4:41 PM, Nate Klingenstein <n...@internet2.edu> wrote:

Will,

You're getting very close.  I assume it never asked you to authenticate.  You need to configure the IdP to request authentication in some form.  By default, it uses REMOTE_USER based authentication.  Try looking at the documentation here, and let me know if you have troubles:

https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn

Ok...I have a login page! w00t.

I have it configured to use a jaas login module.

Going a LITTLE bit off the reservation by using my own custom login module, but it's a trivial example from the JAAS tutorial.

I have printlns in the login module, but I don't see any activity in any of the logs (idp-process, any of the tomcat logs).

However, I'm not getting any errors either.

Here is the LoginHandler tag in the conf/handler.xml of the IdP:

    <!--  Username/password login handler -->
    <LoginHandler xsi:type="UsernamePassword"
                  jaasConfigurationLocation="file:///opt/shib-idp/conf/login.config">
        <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthenticationMethod>
    </LoginHandler>

This is my login.conf file
ShibUserPassAuth {

// Example LDAP authentication
// See: https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass
/*
   edu.vt.middleware.ldap.jaas.LdapLoginModule required
      host="ldap.example.org"
      base="ou=people,dc=example,dc=org"
      ssl="true"
      userField="uid";
*/

// Example Kerberos authentication, requires Sun's JVM
// See: https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass
/*
   com.sun.security.auth.module.Krb5LoginModule required
      useKeyTab="true"
      keyTab="/path/to/idp/keytab/file";
*/
    pkg.jaas.SampleLoginModule required debug="true";

};

Is there any place or a setting I could make to get some more logging information? My login module is laced with printlns but I don't see them anywhere, so I don't even know if the module is being loaded.

I can smell it! I see the light at the end of the tunnel...hopefully, it's not a train.

Thanx again for all your help.

Regards,

Will Hartung

[Brent Putman]

Will Hartung wrote:
>
>
>
> Is there any place or a setting I could make to get some more logging
> information?

Well, for the Shib components you can up the the logging level in
conf/logging.xml.

> My login module is laced with printlns but I don't see them
> anywhere, so I don't even know if the module is being loaded.
>

If it's just printing to stderr or stdout, then if you're using Tomcat
it will be in catalina.out. If you're using some other container,
you'll have to check where it sends stdout and stderr.

[Brent Putman]

Brent Putman wrote:

Will Hartung wrote:
  

Is there any place or a setting I could make to get some more logging
information? 
    

Well, for the Shib components you can up the the logging level in
conf/logging.xml.
  

Meant to supply a link to the wiki docs for IdP logging:

https://spaces.internet2.edu/display/SHIB2/IdPLogging

[Will Hartung]

On Fri, Jan 30, 2009 at 5:16 PM, Brent Putman <put...@georgetown.edu> wrote:

If it's just printing to stderr or stdout, then if you're using Tomcat
it will be in catalina.out.  If you're using some other container,
you'll have to check where it sends stdout and stderr.

Yea, that's what I would think.

After tweaking logging.xml to DEBUG,

    <logger name="edu.internet2.middleware.shibboleth">
        <level value="DEBUG" />
    </logger>

I get this:

01:24:35.606 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:326] - Authenticating user with login handler of type edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler
01:24:35.608 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler:75] - Redirecting to http://ssovm:8080/idp/Authn/UserPassword
01:24:35.667 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:142] - Redirecting to login page /login.jsp
01:24:47.705 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:163] - Attempting to authenticate user gorp
01:24:47.714 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:192] - User authentication for [gorp] failed
01:24:47.716 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:142] - Redirecting to login page /login.jsp


so, it sees the handler, it "tries" it (well, it tries something), and it fails...but I don't think that it's seeing my module. But I find it interesting I'm not getting an error either.

For the record, my module is in a jar in $CATALINA/shared/lib, that should be on the classpath.

Any other thoughts?

Regards,

Will Hartung

[Will Hartung]

I guess it's not actually loading my module. I renamed it in the login.conf, and it didn't fail.

But I still get the same behavior in the log of it trying the authenticator and failing.

Regards,

Will Hartung

[Brent Putman]

Just cleaning out my mail, I forgot about this thread from Friday...

You might also try setting the LoginContext debug trace system
property. It might give you some info as to why your JAAS module is
failing to get loaded. E.g. -Djava.security.auth.debug=logincontext

I believe that unambiguously does go to stderr, so look in Tomcat's
catalina.out for that output.

>
> For the record, my module is in a jar in $CATALINA/shared/lib, that
> should be on the classpath.

So, sounds like you are using Tomcat and probably version 5.5 (since 6
did away with the shared classloader by default). I think using the
shared classloader ought to work, but not 100% sure via-a-vis the way
JAAS works...

If you still haven't had success, just for the sake of troubleshooting
I'd try moving your JAAS module jar(s) into the IdP's webapp classloader
(inside the war in /WEB-INF/lib). That's where the LDAP module that we
supply is, and we know that that works. If your module still won't work
there, then you've got some other kind of problem.

--Brent