[cas-dev] Trouble with Custom Principal/CredentialToPrincipalResolver
Sean R. McNamara
sean.r.mcnamara at Dartmouth.EDU
Wed Mar 19 15:16:03 EDT 2008
I'm following up to the comment I posted on the JIRA issue related to
this: What is the latest version that does not exhibit this
behavior? (namely the latest version w/o the Services Manager
implemented?)
Have there been reports of other's having similar issues? I get the
feeling it's not too common for folks to implement their own Principals...
Thanks..
..Sean.
Scott Battaglia wrote:
> On Tue, Mar 18, 2008 at 3:37 PM, Sean R. McNamara
> <sean.r.mcnamara at dartmouth.edu <mailto:sean.r.mcnamara at dartmouth.edu>>
> wrote:
>
> 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?
>
>
> Yep, I was thinking of making it a configurable option (I just
> neglected to mention that). Glad we're on the same wavelength though ;-)
>
> -Scott
>
>
>
> 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>
> <mailto: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>>
> > <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:
> > >
> > > 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>>
> > > <mailto: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>>
> > <mailto: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>>>
> > > <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
> <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>>>
> > > <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
> <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>>
> > <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
> > > >
> > >
> > > _______________________________________________
> > > 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