[cas-dev] Trouble with Custom Principal/CredentialToPrincipalResolver
Sean R. McNamara
sean.r.mcnamara at Dartmouth.EDU
Tue Mar 18 15:37:55 EDT 2008
Scott,
Gotcha -- makes complete sense now. Thanks for the detailed
explanation. The exception sounds like a great idea, but, I wonder
whether or not it might be worthwhile to make it toggleable via a
properties file or what not.
My worry is that there might be folks out there who are inadvertently
using this behavior to their advantage somehow and the outright
exception may break their implementations.
What do you think?
Thanks..
..Sean.
Scott Battaglia wrote:
> Sean,
>
> What's happening is that in the latest version of CAS we have a
> Services Management tool which decides which services see which
> attributes. It makes one underlying (potentially bad)
> assumption...that every Principal is an instance of SimplePrincipal.
> The principal returned on validation isn't the principal you created
> in the resolver (that's still in memory) but its a new principal with
> the rules from the Services Management tool applied to it.
>
> If you used the new Services Management tool (where you can specify a
> set of default attributes) along with the PersonDirectory support you
> wouldn't see this.
>
> Likewise, I can add an exemption for non SimplePrincipal principals.
>
> -Scott
>
> On Tue, Mar 18, 2008 at 2:51 PM, Sean R. McNamara
> <sean.r.mcnamara at dartmouth.edu <mailto:sean.r.mcnamara at dartmouth.edu>>
> wrote:
>
> 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>
> <mailto: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>
> > <mailto: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>
> <mailto: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>>
> > <mailto: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>>
> > <mailto: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>
> <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
> > >
> >
> > _______________________________________________
> > 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