Hi Carl, You read it correctly. Calling the service validation stuff as https://<server>/cas/p3/serviceValidate does indeed use protocol 3 and returns those attributes as released through the service definition. The XML generated returns the released attributes wrapped in <cas:attribute> tags.
Dave On 8/29/14 2:15 PM, Waldbieser, Carl wrote: > Dave, > > 'cas-server-webapp/src/main/webapp/WEB-INF/cas-servlet.xml' seems to contain > references to both 'cas3ServiceSuccessView' and 'cas2ServiceSuccessView'. > > It looks to me like this section is relevant: > > <prop key="/p3/serviceValidate">v3ServiceValidateController</prop> > <prop key="/p3/proxyValidate">v3ProxyValidateController</prop> > > I would read that to mean that your base URL should be '/cas/p3' rather than > just '/cas'. > > Thanks, > Carl Waldbieser > Systems Programmer > Lafayette College > > > ----- Original Message ----- > From: "David A. Kovacic" <d...@case.edu> > To: cas-user@lists.jasig.org > Sent: Friday, August 29, 2014 1:17:30 PM > Subject: Re: [cas-user] CAS 4.0.0: LDAP Attribute Repository - I think I have > it working - How to verify? - Someone PLEASE respond > > I did find pycas.py out on the web and am dumping the raw response which > is returning: > > <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> > <cas:authenticationSuccess> > <cas:user>rat9</cas:user> > > > </cas:authenticationSuccess> > </cas:serviceResponse> > > I think I did find the issue though: Even though the docs state the > 4.0.0 is implementing the CAS 3.0 protocol, the CAS 2.0 > casServiceValidationSuccess.jsp from the protocol/2.0 directory is being > used when validating using https://<server>/cas/serviceValidate to > validate the service ticket. Modifying the protocol 2.0 > casServiceValidationSuccess.jsp DOES release attributes, although they > don't seem to be controlled in any way by the attributes you tell it to > allow or ignore. > > Do you have any idea how to tell it to use protocol 3 instead of 2? Is > it a different URI than serviceValidate, or a prameter or something? > > Dave > > On 8/28/14 6:11 PM, Carl Waldbieser wrote: >> David, >> >> The easiest way would be to have a CAS client try to validate a >> service ticket and observe the response. >> >> You can simulate this with cURL (request /login, get the LT, POST to >> get an ST, then GET /serviceValidate to validate the ticket). >> >> If yout ticket timeouts are to small for you to pull that off, you can >> throw a script together to do the same, or even better use something >> like the PHPCas client and crank up the debugging so you can see the >> response to /serviceValidate. >> >> I have a test service I run that dumps the results to a web page to >> make it simple. It is written in Python. If you can't use one of the >> above methods, you are welcome to use the script. >> >> Thanks, >> Carl Waldbieser >> >> >> >> On Thu, Aug 28, 2014 at 5:06 PM, David A. Kovacic <d...@case.edu >> <mailto:d...@case.edu>> wrote: >> >> All, >> >> After much trial and error I believe I have LDAP attribute retrieval >> under 4.0.0 working, at least I am seeing searches in our LDAP logs. >> Unfortunately, I am unsure how to verify if CAS is indeed storing >> those >> values it gets back in the principal as it is supposed to, or if it is >> just silently discarding them. In short, is there some way to >> dump the >> principal after authentication, or some other way to tell if the >> attributes have been properly stored. I am doing a straight 4.0.0 >> deployment to production from rubyCAS so I have no 3.5.2 >> experience (or >> production server) to fall back on. My deadline for deployment is >> fast >> approaching, and the concentration of answers in cas-user seems to be >> all for 3.5.2. I at least am starting to get slightly desperate..... >> >> If someone can PLEASE take a look here and tell me how to verify >> or not >> whether this is now actually correctly working. If you can at least >> point me in the direction so I can do my own debugging, I would >> appreciate it. >> >> For those others that have been struggling with this, here's what >> I did >> to get this working: >> >> From the ldapAuthenticationManager bean" >> >> <bean id="ldapAuthenticationHandler" >> >> class="org.jasig.cas.authentication.LdapAuthenticationHandler" >> >> p:principalIdAttribute="uid" >> <!-- This seems to need to be the LDAP attribute to search on --> >> c:authenticator-ref="authenticator"> >> <property name="principalAttributeMap"> >> <map> >> <!-- >> | This map provides a simple attribute resolution >> mechanism. >> | Keys are LDAP attribute names, values are CAS >> attribute names. >> | Use this facility instead of a >> PrincipalResolver if >> LDAP is >> | the only attribute source. >> --> >> <entry key="uid" value="user" >> /> <!-- This maps CAS "user" to >> LDAP "uid" does this go in the principal??? --> >> <entry key="mail" value="mail" /> >> <entry key="cn" value="displayName" /> >> <entry key="eduPersonPrincipalName" >> value="eduPersonPrincipalName" /> >> </map> >> </property> >> </bean> >> >> This is the definition of the "primaryPrincipalResolver" that seems to >> finally be working: >> >> <!-- >> | Resolves a principal from a credential using an attribute >> repository that is configured to resolve >> | against a deployer-specific store (e.g. LDAP). >> --> >> <bean id="primaryPrincipalResolver" >> >> >> class="org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver" >> > >> <property name="attributeRepository" >> ref="attributeRepository" /> >> </bean> >> >> <!-- >> Bean that defines the attributes that a service may return. This >> example uses the Stub/Mock version. A real implementation >> may go against a database or LDAP server. The id should remain >> "attributeRepository" though. >> +--> >> <bean id="attributeRepository" >> >> class="org.jasig.cas.persondir.LdapPersonAttributeDao" >> <!-- NOTE: Do NOT use >> org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao --> >> p:baseDN="${ldap.authn.baseDn}" >> >> p:searchFilter="uid={0}" >> <!-- For some reason using a property defined in cas.properties >> does NOT >> replace the variable --> >> p:searchControls-ref="searchControls" >> >> p:connectionFactory-ref="searchPooledLdapConnectionFactory" >> <!-- Using the same pooled connection for authentications --> >> p:resultAttributeMapping-ref="resultAttributeMap" >> /> <!-- Originally had a >> queryAttributeMapping-ref in here as well --> >> >> <!-- removing the queryAttribute.... got things working --> >> >> <util:map id="resultAttributeMap"> >> <entry key="uid" value="user" /> >> <entry key="mail" value="email" /> >> <entry key="cn" value="displayName" /> >> <entry key="eduPersonPrincipalName" >> value="eduPersonPrincipalName" /> >> </util:map> >> >> <bean id="searchControls" >> class="javax.naming.directory.SearchControls" >> p:searchScope="2" >> /> <!-- >> This sets >> subtree searches --> >> >> This is what we are seeing now in our LDAP logs....... >> This is the search by the authenticaion special user to get the DN of >> our test user (floober) >> [28/Aug/2014:16:00:45 -0400] conn=10371 op=2 msgId=3 - SRCH >> base="o=cwru.edu <http://cwru.edu>,o=isp" scope=2 >> filter="(uid=floober)" attrs="1.1" >> [28/Aug/2014:16:00:45 -0400] conn=10371 op=2 msgId=3 - RESULT err=0 >> tag=101 nentries=1 etime=0 >> >> This is the actual authentication BIND test >> [28/Aug/2014:16:00:45 -0400] conn=10368 op=1 msgId=2 - BIND >> dn="uid=floober,ou=Delegated Accounts,o=cwru.edu >> <http://cwru.edu>,o=isp" method=128 version=3 >> [28/Aug/2014:16:00:45 -0400] conn=10368 op=1 msgId=2 - RESULT err=0 >> tag=97 nentries=0 etime=56 dn="uid=floober,ou=delegated >> accounts,o=cwru.edu <http://cwru.edu>,o=isp" >> >> As far as I can tell this search populates the principalAttributeMap >> from the authentication handler. Note that uid is requested twice - >> once for the "principalIdAttribute" property and once to map it to the >> principal name of "user" - hopefully this does not break anything >> since >> the and LDAP search with repeated attributes will only return the >> attribute once. >> [28/Aug/2014:16:00:45 -0400] conn=10368 op=2 msgId=3 - SRCH >> base="uid=floober,ou=delegated accounts,o=cwru.edu >> <http://cwru.edu>,o=isp" scope=0 >> filter="(objectClass=*)" attrs="uid uid mail cn >> eduPersonPrincipalName" >> [28/Aug/2014:16:00:45 -0400] conn=10368 op=2 msgId=3 - RESULT err=0 >> tag=101 nentries=1 etime=0 >> >> This seems to be the "attributeRepository" search. An entry is >> returned >> with the proper attributes, so this >>>SHOULD<<< be properly >> populating >> the attribute repository and the principal. >> [28/Aug/2014:16:00:45 -0400] conn=10371 op=3 msgId=4 - SRCH >> base="o=cwru.edu <http://cwru.edu>,o=isp" scope=2 >> filter="(uid=floober)" attrs="uid mail >> cn eduPersonPrincipalName" >> [28/Aug/2014:16:00:45 -0400] conn=10371 op=3 msgId=4 - RESULT err=0 >> tag=101 nentries=1 etime=0 >> >> Thanks, >> Dave >> >> >> -- >> You are currently subscribed to cas-user@lists.jasig.org >> <mailto:cas-user@lists.jasig.org> as: cwaldbie...@gmail.com >> <mailto:cwaldbie...@gmail.com> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> >> -- >> You are currently subscribed to cas-user@lists.jasig.org as: d...@case.edu >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
