[cas-dev] Trouble with Custom Principal/CredentialToPrincipalResolver
Sean R. McNamara
sean.r.mcnamara at Dartmouth.EDU
Tue Mar 18 14:51:33 EDT 2008
Scott,
Okay, will do. But, I'm still a little unclear on exactly what's
happening. Admittedly, I'm not too familiar with the new Services
Management tool.
You think the services management tool is forcing the
casServiceValidationSuccess.jsp to interpret the Principal as a
SimplePrincipal regardless of the true type?
Off hand, can you think of any work around? Perhaps a way to disable
this functionality? If I was to re-do our custom code and follow the
model given by AbstractPersonDirectoryCredentialsToPrincipalResolver,
would that resolve this problem? Even then, I'm not totally clear on
what's happening on the casServiceValidation....jsp side of the house.
Thanks again for your help.
..Sean.
..Sean.
Scott Battaglia wrote:
> I believe I know what it is. You've fallen prey to our new attribute
> support where we support attributes via a Map on the and use the
> Services Management tool to control what you have access to.
>
> If you can add a JIRA issue for "Services Management tool should
> ignore custom principals" with the appropriate details I can add that
> in to the code so that it will only apply the Services Management
> features to derivatives to our SimplePrincipal.
>
> -Scott
>
> On Tue, Mar 18, 2008 at 12:06 PM, Sean R. McNamara
> <sean.r.mcnamara at dartmouth.edu <mailto:sean.r.mcnamara at dartmouth.edu>>
> wrote:
>
> Scott,
>
> After adding a bit more debugging to the credentials, I see that it is
> being called:
>
> 2008-03-18 11:41:35,845 DEBUG
> [edu.dartmouth.cas.authentication.principal.DartmouthUsernamePasswordCredentialsToPrincipalResolver]
> - Created DartmouthPrincipal for [Sean R. McNamara at DARTMOUTH.EDU
> <mailto:McNamara at DARTMOUTH.EDU>]
> 2008-03-18 11:41:35,861 INFO
> [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service
> ticket [ST-1-H9poUepzEq52rfqVklWe-cas-test1] for service
> [http://dev.dartmouth.edu/fake/index.html] for user [Sean R.
> McNamara at DARTMOUTH.EDU <mailto:McNamara at DARTMOUTH.EDU>]
>
> The DartmouthPrincipal has a few additional attributes added to it
> beyond SimplePrincipal.
>
> I'm attempting to reference those attributes in
> casServiceValidationSuccess.jsp as follows:
>
>
> <cas:user>${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.id)}</cas:user>
>
> <cas:uid>${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.uid)}</cas:uid>
>
> <cas:did>${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.did)}</cas:did>
>
> <cas:affil>${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.affil)}</cas:affil>
>
> <cas:authType>${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.authType)}</cas:authType>
>
> However, this results in the following exception:
>
> org.apache.jasper.JasperException: Unable to find a value for "uid" in
> object of class
> "org.jasig.cas.authentication.principal.SimplePrincipal"
> using operator "."
>
> org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:510)
> <truncated>
>
> This code worked fine in 3.0.6, but only after being moved to 3.2
> started failing. I'm having trouble understanding why
> casServiceValidationSuccess is seeing the Principal as a
> SimplePrincipal
> and not as a DartmouthPrincipal as the debugging seems to indicate was
> instantiated. Has something changed since 3.0.6 where I need to make
> the Principal type explicit?
>
> Thanks for your help!
>
> ..Sean.
>
> Scott Battaglia wrote:
> > Sean,
> >
> > The only way your CredentialsToPrincipalResolver would not get
> called
> > would be if there was one higher up in the list than yours that
> > matched the principal. Check to see if there are any other
> > CredentialsToPrincipalResolvers configured that may be executed
> before
> > your custom one.
> >
> > -Scott
> >
> > On Mon, Mar 17, 2008 at 8:21 PM, Sean R. McNamara
> > <sean.r.mcnamara at dartmouth.edu
> <mailto:sean.r.mcnamara at dartmouth.edu>
> <mailto:sean.r.mcnamara at dartmouth.edu
> <mailto:sean.r.mcnamara at dartmouth.edu>>>
> > wrote:
> >
> > Hello all,
> >
> > I just recently inherited a 3.0.6 CAS environment, and am
> working to
> > upgrade to 3.2 and implement clustering.
> >
> > We have a handful of customizations built into our server,
> namely a
> > custom Authentication Handler and Principal.
> >
> > I'm struggling to understand exactly how a set of
> credentials are
> > matched to a particular Principal type. Basically what I am
> > seeing is
> > that our customizations work fine in the 3.0.6 build, but
> once moved
> > over and built into 3.2, no longer work as expected.
> >
> > The custom Auth. Handler validates the credentials
> appropriately,
> > however it appears the credentials are being identified as a
> > SimplePrincipal when I try to do a service validation after
> being
> > issued
> > a ticket. I know this since I get a exception telling me
> that the
> > custom attributes I'm referencing (added to
> > casServiceValidationSuccess.jsp) cannot be accessed in a
> > SimplePrincipal
> > object.
> >
> > I've seen some mention of a LoginFormAction to specify what
> type of
> > Principal should be used, but, AFAIK -- this is no longer
> valid in 3.X
> > releases. Of course there's a
> CredentialToPrincipalResolver (and is
> > set in deployerConfigContex), but, the odd thing is -- it
> doesn't
> > appear to be being called. As a test, I changed the supports
> > method to
> > always return true, and still had no luck. Interestingly, the
> >
> > I know I'm not giving a lot to go on, so if anyone needs any
> technical
> > details, I can send them along tomorrow AM. In the
> meantime, if
> > anyone
> > has any pointers or can see any red flags from what I've
> explained so
> > far, I'd appreciate the heads up.
> >
> > Thanks very much in advance!
> >
> > ..Sean.
> >
> > _______________________________________________
> > cas-dev mailing list
> > cas-dev at tp.its.yale.edu <mailto:cas-dev at tp.its.yale.edu>
> <mailto:cas-dev at tp.its.yale.edu <mailto:cas-dev at tp.its.yale.edu>>
> > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >
> >
> >
> >
> > --
> > -Scott Battaglia
> > PGP Public Key Id: 0x383733AA
> > LinkedIn: http://www.linkedin.com/in/scottbattaglia
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > cas-dev mailing list
> > cas-dev at tp.its.yale.edu <mailto:cas-dev at tp.its.yale.edu>
> > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu <mailto:cas-dev at tp.its.yale.edu>
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
>
>
> --
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> ------------------------------------------------------------------------
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
More information about the cas-dev
mailing list