Login jsp idpui for CAS

[O'Dowd, Josh]

I ran the same test login scenario against an OOB implementation of IdP3 with CAS protocol enabled; restart jetty, login/logout from a SAML2 SP, try CAS service login.  Sorry to report same results.  I am including a similar idp-process.log  excerpt from this test run.

One point of interest…  I wanted to check out the source for the class that is referenced in this log entry:
2015-11-03 10:12:24,760 - DEBUG [net.shibboleth.idp.cas.flow.BuildRelyingPartyContextAction:83] - Setting up RP context for verified relying party http://10.10.18.162:7080/cas-sample/j_spring_cas_security_check
…  the source repo has the class BuildRelyingPartyContextAction in a different package, net.shibboleth.idp.cas.flow.impl.  Maybe I am not browsing the repo correctly?

Anyway, here is the most recent log excerpt:
2015-11-03 10:12:21,214 - DEBUG [net.shibboleth.idp.session.impl.StorageBackedIdPSession:602] - Loading SPSession for service http://wts-staging1.ito.umt.edu/Shibboleth.sso in session 24bf133b7cba7a11f39b57176ab0eeaaafff9f244886a2d0de59bb9fbbc5639b
2015-11-03 10:12:21,214 - DEBUG [net.shibboleth.idp.session.SPSessionSerializerRegistry:86] - Registry located StorageSerializer of type 'net.shibboleth.idp.saml.session.impl.SAML2SPSessionSerializer' for SPSession type 'class net.shibboleth.idp.saml.session.SAML2SPSession'
2015-11-03 10:12:21,216 - DEBUG [net.shibboleth.idp.saml.saml2.profile.impl.ProcessLogoutRequest:272] - Profile Action ProcessLogoutRequest: LogoutRequest matches IdP session 24bf133b7cba7a11f39b57176ab0eeaaafff9f244886a2d0de59bb9fbbc5639b
2015-11-03 10:12:21,216 - DEBUG [net.shibboleth.idp.session.impl.StorageBackedSessionManager:521] - Destroyed session 24bf133b7cba7a11f39b57176ab0eeaaafff9f244886a2d0de59bb9fbbc5639b
2015-11-03 10:12:21,219 - DEBUG [net.shibboleth.idp.profile.audit.impl.PopulateAuditContext:220] - Profile Action PopulateAuditContext: Adding 1 value for field 'u'
2015-11-03 10:12:21,219 - DEBUG [net.shibboleth.idp.profile.audit.impl.PopulateAuditContext:220] - Profile Action PopulateAuditContext: Adding 1 value for field 'n'
2015-11-03 10:12:21,219 - DEBUG [net.shibboleth.idp.profile.audit.impl.PopulateAuditContext:198] - Profile Action PopulateAuditContext: Skipping field 's' not included in audit format
2015-11-03 10:12:21,229 - ERROR [org.apache.velocity:96] - ResourceManager : unable to find resource 'logout.vm' in any resource loader.
2015-11-03 10:12:24,760 - DEBUG [net.shibboleth.idp.session.impl.PopulateSessionContext:131] - Profile Action PopulateSessionContext: No session found for client
2015-11-03 10:12:24,760 - DEBUG [net.shibboleth.idp.cas.service.PatternServiceRegistry:60] - Evaluating whether http://10.10.18.162:7080/cas-sample/j_spring_cas_security_check matches ^(http|https)://.*?
2015-11-03 10:12:24,760 - DEBUG [net.shibboleth.idp.cas.service.PatternServiceRegistry:62] - Found match
2015-11-03 10:12:24,760 - DEBUG [net.shibboleth.idp.cas.flow.BuildRelyingPartyContextAction:83] - Setting up RP context for verified relying party http://10.10.18.162:7080/cas-sample/j_spring_cas_security_check
2015-11-03 10:12:24,761 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:284] - Resolving relying party configuration
2015-11-03 10:12:24,761 - DEBUG [net.shibboleth.idp.relyingparty.impl.DefaultRelyingPartyConfigurationResolver:305] - No relying party configurations are applicable, returning the default configuration shibboleth.DefaultRelyingParty
2015-11-03 10:12:24,761 - DEBUG [net.shibboleth.idp.profile.impl.SelectRelyingPartyConfiguration:136] - Profile Action SelectRelyingPartyConfiguration: Found relying party configuration shibboleth.DefaultRelyingParty for request
2015-11-03 10:12:24,762 - DEBUG [net.shibboleth.idp.cas.flow.CheckAuthenticationRequiredAction:82] - IdP session not found
2015-11-03 10:12:24,762 - DEBUG [net.shibboleth.idp.authn.impl.PopulateAuthenticationContext:125] - Profile Action PopulateAuthenticationContext: Installing custom PrincipalEvalPredicateFactoryRegistry into AuthenticationContext
2015-11-03 10:12:24,763 - DEBUG [net.shibboleth.idp.authn.impl.PopulateAuthenticationContext:158] - Profile Action PopulateAuthenticationContext: Installed 1 authentication flows into AuthenticationContext
2015-11-03 10:12:24,763 - DEBUG [net.shibboleth.idp.session.impl.PopulateSessionContext:131] - Profile Action PopulateSessionContext: No session found for client
2015-11-03 10:12:24,763 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByForcedAuthn:53] - Profile Action FilterFlowsByForcedAuthn: Request does not have forced authentication requirement, nothing to do
2015-11-03 10:12:24,764 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByPassivity:53] - Profile Action FilterFlowsByPassivity: Request does not have passive requirement, nothing to do
2015-11-03 10:12:24,764 - DEBUG [net.shibboleth.idp.authn.impl.FilterFlowsByNonBrowserSupport:53] - Profile Action FilterFlowsByNonBrowserSupport: Request does not have non-browser requirement, nothing to do
2015-11-03 10:12:24,764 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:241] - Profile Action SelectAuthenticationFlow: No specific Principals requested
2015-11-03 10:12:24,764 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:267] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow
2015-11-03 10:12:24,764 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:309] - Profile Action SelectAuthenticationFlow: Selecting inactive authentication flow authn/Password
2015-11-03 10:12:24,765 - DEBUG [net.shibboleth.idp.authn.impl.ExtractUsernamePasswordFromBasicAuth:115] - Profile Action ExtractUsernamePasswordFromBasicAuth: No appropriate Authorization header found
2015-11-03 10:12:24,773 - DEBUG [net.shibboleth.idp.ui.context.RelyingPartyUIContext:744] - Returning logo from UIInfo, 'en' (150 x 150) : https://www.umt.edu/templates/imx/idp_logo_test.png
2015-11-03 10:12:24,774 - DEBUG [net.shibboleth.idp.ui.context.RelyingPartyUIContext:264] - Acceptable Scheme 'https', returning value 'https://www.umt.edu/templates/imx/idp_logo_test.png'
2015-11-03 10:12:24,775 - DEBUG [net.shibboleth.idp.ui.context.RelyingPartyUIContext:310] - Returning name from UIInfo 'Staging 1 SP'
2015-11-03 10:12:24,775 - DEBUG [net.shibboleth.idp.ui.context.RelyingPartyUIContext:551] - Returning OrganizationDisplayName from Organization, University of Montana, WTS-Staging1

-Josh

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Marvin Addison
Sent: Tuesday, November 3, 2015 4:59 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Login jsp idpui for CAS

The following is an excerpt from the idp-process.log in DEBUG, as requested.  I restarted our Jetty server, then I did a single SAML2 authentication using our testing SP (WTS-Staging1).  I then logged out and browse to our sample CAS protected URL.  The login page branding I am presented with is the UIInfo from the WTS-Staging1 SP.
The logs show what I'd expect other than the existence of an RelyingPartyUIContext, which simply doesn't get populated by the CAS protocol flow. While the CAS login flow does set up a SAMLMetadataContext, which is a precondition of SetRPUIInformation, none of the fields are set that are needed to build the RPUICtx in the authn/password flow.

Do you have a test environment where you can configure the standard authn/password flow and repeat your test sequence againt that? If you still see that behavior in a "default" case, then it would be stronger evidence that it's not some custom code causing the problem.

M

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20151103/627e02a0/attachment-0001.html>