[cas-user] Re: Error parsing incommon metadata

Rather than fetching the entire (huge) InCommon metadata aggregate for each service, it might work better to use the metadata query capability in your service definitions to do a dynamic query for just

Re: [cas-user] Re: Multiple SAML Federated SP

I don't think auto-generating individual service definitions for every SP in a large federation is the right approach - why clutter CAS with thousands of (mostly) unused service definitions? In any case, at least for InCommon, best practice is use the metadata query service to query individual

Re: [cas-user] Re: Multiple SAML Federated SP

We've had good success with wildcard service definitions for a single federation (InCommon), using a definition like: "@class" : "org.apereo.cas.support.saml.services.SamlRegisteredService", "serviceId" : ".+", "name" : "InCommon", "evaluationOrder" : , "metadataLocation" :

[cas-user] Re: cas 6.6.X : saml client : Authentication statement is too old error

Yes, it is a bug -- in CAS 5. CAS 6 is doing the right thing here; it was the old version of CAS that had it wrong. The SAML AuthnInstant is supposed to indicate when authentication occured (when the user entered their password TGT was issued), not when the most recent service ticket was

[cas-user] Re: [cas-dev] CAS registry migration

verywhere. On Tuesday, December 14, 2021 at 9:05:51 AM UTC-5 David Gelhar wrote: > That message might mean that you're missing the OIDC dependency in your > build.gradle > > Make sure you have something like > > implementation > "org.apereo.cas:cas-server-support-o

[cas-user] Re: [cas-dev] CAS registry migration

That message might mean that you're missing the OIDC dependency in your build.gradle Make sure you have something like implementation "org.apereo.cas:cas-server-support-oidc:${project.'cas.version'}" > On Dec 14, 2021, at 8:28 AM, Jeffrey Ramsay wrote: > > Hello - > > What is the

Re: [cas-user] CAS 6.1.x Ldaps configuration problem

Using Java8 probably isn't an option - CAS 6.x requires Java11 We have been able to work around the issue by using the UnboundID provider as suggested, with settings like this: cas.properties : cas.authn.ldap[0].providerClass= org.ldaptive.provider.unboundid.UnboundIDProvider build.gradle: //

[cas-user] phpCAS: dumb question --- which certificate to use for validation of server?

The client needs to be configured to accept the certificate that’s used by the cas server it’s connecting to: $cas_host and $cas_port in the example. Generally you will want to configure it with the Certificate Authority (CA) certificate of the authority that issued the certificate, not the