Glad that it worked for you! If any of our documentation is weak, please feel free to help us fix it!
Cheers, Scott On Mon, May 17, 2010 at 9:27 AM, Acevedo User <[email protected]> wrote: > Thank you! Looked like Greek to me on Friday, today it made perfect > sense. > > For the record here is what I had to do: > > Cas Client web.xml > > <filter> <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name> > > <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> > <init-param> > <param-name>roleAttribute</param-name> > <param-value>Roles</param-value> > </init-param> > </filter> > > Then in the Cas client jsp file: > > <%if (request.isUserInRole(" PersonInfo")) { %> <b>You have the > role PersonInfo!<b> <% } %> > > On 5/15/10 12:06 AM, "Scott Battaglia" <[email protected]> wrote: > > I'm not sure I follow. You're trying to use the attributes in your CAS > client. So I'm not sure why you're showing me server configuration (unless > I'm misunderstanding you). > > If you're using this: > > https://www.ja-sig.org/svn/cas-clients/java-client/trunk/cas-client-core/src/main/java/org/jasig/cas/client/util/HttpServletRequestWrapperFilter.java > > You can specify the attribute to use for roles as part of your config (the > init-param is "roleAttribute"). > > Cheers, > Scott > > > On Fri, May 14, 2010 at 4:01 PM, Acevedo User <[email protected]> wrote: > > Do you mean the ldapAuthProvider bean? Below is my config file. I have > the ldap provider bean commented out because I could not get it working and > was going to try again later. > > My deployerConfigContext.xml > > <code> > <?xml version="1.0" encoding="UTF-8"?> <!-- | deployerConfigContext.xml > centralizes into one file some of the declarative configuration that | > all CAS deployers will need to modify. | | This file declares some of > the Spring-managed JavaBeans that make up a CAS deployment. | The beans > declared in this file are instantiated at context initialization time by the > Spring | ContextLoaderListener declared in web.xml. It finds this file > because this | file is among those declared in the context parameter > "contextConfigLocation". | | By far the most common change you will > need to make in this file is to change the last bean | declaration to > replace the default SimpleTestUsernamePasswordAuthenticationHandler with > | one implementing your approach for authenticating usernames and > passwords. +--> <beans xmlns=" > http://www.springframework.org/schema/beans < > http://www.springframework.org/schema/beans> " xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance"; xmlns:p=" > http://www.springframework.org/schema/p < > http://www.springframework.org/schema/p> " xmlns:security=" > http://www.springframework.org/schema/security < > http://www.springframework.org/schema/security> " > xsi:schemaLocation="http://www.springframework.org/schema/beans > http://www.springframework.org/schema/beans/spring-beans-2.0.xsd > http://www.springframework.org/schema/security > http://www.springframework.org/schema/security/spring-security-2.0.xsd"; < > http://www.springframework.org/schema/security/spring-security-2.0.xsd%22> > > <!-- | This bean declares our AuthenticationManager. The > CentralAuthenticationService service bean | declared in > applicationContext.xml picks up this AuthenticationManager by reference to > its id, | "authenticationManager". Most deployers will be able to > use the default AuthenticationManager | implementation and so do not > need to change the class of this bean. We include the whole | > AuthenticationManager here in the userConfigContext.xml so that you can see > the things you will | need to change in context. +--> <bean > id="authenticationManager" > class="org.jasig.cas.authentication.AuthenticationManagerImpl"> > <!-- | This is the List of CredentialToPrincipalResolvers > that identify what Principal is trying to authenticate. | The > AuthenticationManagerImpl considers them in order, finding a > CredentialToPrincipalResolver which | supports the presented > credentials. | | AuthenticationManagerImpl uses these > resolvers for two purposes. First, it uses them to identify the Principal > | attempting to authenticate to CAS /login . In the default > configuration, it is the DefaultCredentialsToPrincipalResolver | > that fills this role. If you are using some other kind of credentials than > UsernamePasswordCredentials, you will need to replace | > DefaultCredentialsToPrincipalResolver with a CredentialsToPrincipalResolver > that supports the credentials you are | using. | > | Second, AuthenticationManagerImpl uses these resolvers to > identify a service requesting a proxy granting ticket. | In the > default configuration, it is the > HttpBasedServiceCredentialsToPrincipalResolver that serves this purpose. > | You will need to change this list if you are identifying > services by something more or other than their callback URL. +--> > <property name="credentialsToPrincipalResolvers"> <list> > <bean > class="org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolver"> > <!-- The Principal resolver form the credentials --> > <property name="credentialsToPrincipalResolver"> > <bean > class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPrincipalResolver" > /> </property> <!-- > The query made to find the Principal ID. > "%u" will be replaced by the resolved Principal > --> <property name="filter" > value="(uid=%u)" /> <!-- The attribute used to define > the new Principal ID --> <property > name="principalAttributeName" value="uid" /> <property > name="searchBase" value="ou=People,dc=vccs,dc=edu" /> > <property name="contextSource" ref="contextSource" /> > <property name="attributeRepository"> > <ref bean="attribRepository" /> > </property> </bean> <!-- > | HttpBasedServiceCredentialsToPrincipalResolver supports > HttpBasedCredentials. It supports the CAS 2.0 approach of > | authenticating services by SSL callback, extracting the > callback URL from the Credentials and representing it as a > | SimpleService identified by that callback URL. > | | If you are representing services > by something more or other than an HTTPS URL whereat they are able to > | receive a proxy callback, you will need to change this > bean declaration (or add additional declarations). +--> > <!--<bean > > class="org.jasig.cas.authentication.principal.HttpBasedServiceCredentialsToPrincipalResolver" > />--> </list> </property> <!-- | > Whereas CredentialsToPrincipalResolvers identify who it is some Credentials > might authenticate, | AuthenticationHandlers actually > authenticate credentials. Here we declare the AuthenticationHandlers that > | authenticate the Principals that the > CredentialsToPrincipalResolvers identified. CAS will try these handlers in > turn | until it finds one that both supports the Credentials > presented and succeeds in authenticating. +--> <property > name="authenticationHandlers"> <list> <!-- > | This is the authentication handler that authenticates > services by means of callback via SSL, thereby validating > | a server side SSL certificate. +--> > <bean > class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" > p:httpClient-ref="httpClient" /> <!-- > | This is the authentication handler declaration that > every CAS deployer will need to change before deploying CAS > | into production. The default > SimpleTestUsernamePasswordAuthenticationHandler authenticates > UsernamePasswordCredentials | where the username equals > the password. You will need to replace this with an AuthenticationHandler > that implements your | local authentication strategy. > You might accomplish this by coding a new such handler and declaring > | edu.someschool.its.cas.MySpecialHandler here, or you > might use one of the handlers provided in the adaptors modules. > +--> <bean > class="org.jasig.cas.adaptors.ldap.FastBindLdapAuthenticationHandler" > > <property name="filter" > value="uid=%u,ou=People,dc=vccs,dc=edu" /> <property > name="contextSource" ref="contextSource" /> </bean> > </list> </property> </bean> <!-- This bean > defines the security roles for the Services Management application. Simple > deployments can use the in-memory version. More robust deployments will > want to use another option, such as the Jdbc version. The name of > this should remain "userDetailsService" in order for Acegi to find it. > To use this, you should add an entry similar to the following between the > two value tags: battags=notused,ROLE_ADMIN where battags is the > username you want to grant access to. You can put one entry per line. > --> <bean id="userDetailsService" > class="org.springframework.security.userdetails.memory.InMemoryDaoImpl"> > <property name="userMap"> <value> </value> > </property> </bean> <bean id="contextSource" > class="org.springframework.security.ldap.DefaultSpringSecurityContextSource"> > <constructor-arg value="ldapserver:389"/> <property name="userDn" > value="user"/> <property name="password" value="xxxxx"/> </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.services.persondir.support.StubPersonAttributeDao"> > <property name="backingMap"> <map> <entry > key="uid" value="uid" /> <entry key="cn" value="Name" /> > <entry key="sn" value="LastName" /> <entry > key="Role" value="Roles"/> <entry key="givenName" > value="Firstname"/> <entry key="mail" value="email"/> > </map> </property> </bean> <bean > id="attribRepository" > class="org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao"> > <property name="contextSource" ref="contextSource" /> <property > name="baseDN" value="ou=People,dc=vccs,dc=edu" /> <property > name="requireAllQueryAttributes" value="true" /> <!-- Attribute mapping > beetween principal (key) and LDAP (value) names used to perform the LDAP > search. By default, multiple search criteria are ANDed together. Set the > queryType property to change to OR. --> <property > name="queryAttributeMapping"> <map> <entry > key="username" value="uid" /> </map> </property> > <property name="resultAttributeMapping"> <map> > <!-- Mapping beetween LDAP entry attributes (key) and Principal's > (value) --> <entry key="cn" value="Name"/> <entry > key="sn" value="LastName"/> <entry key="Role" value="Roles"/> > <entry key="givenName" value="Firstname"/> <entry > key="mail" value="email"/> </map> </property> </bean> > <!-- Sample, in-memory data store for the ServiceRegistry. A real > implementation would probably want to replace this with the JPA-backed > ServiceRegistry DAO The name of this bean should remain > "serviceRegistryDao". --> <bean id = "serviceRegistryDao" class = > "org.jasig.cas.services.InMemoryServiceRegistryDaoImpl"> <property > name="registeredServices"> <list> <bean class = > "org.jasig.cas.services.RegisteredServiceImpl" p:id ="1" > p:description="mywebapp Nova" p:serviceId="**/nova/**" > p:name="mywebapp_nova" p:theme="NOVA" p:allowedToProxy="true" > p:enabled="true" p:ssoEnabled="true" p:anonymousAccess="false"> <property > name="allowedAttributes" value="uid,Name,LastName,Roles,Firstname,email" /> > </bean> <bean class = > "org.jasig.cas.services.RegisteredServiceImpl" p:id ="2" > p:description="mywebapp TCC" p:serviceId="**/tc295/**" p:name="mywebapp_tcc" > p:theme="TC295" p:allowedToProxy="true" p:enabled="true" p:ssoEnabled="true" > p:anonymousAccess="false"> <property name="allowedAttributes" > value="uid,Name,LastName,Firstname" /> </bean> > </list> </property> </bean> <!--<bean id="ldapAuthProvider" > class="org.springframework.security.providers.ldap.LdapAuthenticationProvider"> > <constructor-arg> <bean > class="org.springframework.security.providers.ldap.authenticator.BindAuthenticator"> > <constructor-arg ref="contextSource"/> <property name="userSearch" > ref="userSearch" /> </bean> </constructor-arg> <constructor-arg> <bean > class="org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopulator"> > <constructor-arg ref="contextSource"/> <constructor-arg value=""/> <property > name="groupRoleAttribute" value="Role"/> </bean> </constructor-arg> </bean> > <bean id="userSearch" > class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch"> > <constructor-arg index="0" value=""/> <constructor-arg index="1" > value="(uid={0})"/> <constructor-arg index="2" ref="contextSource" /></bean> > --> </beans> </code> > > > > > On 5/14/10 3:14 PM, "Scott Battaglia" <[email protected] < > http://[email protected]> > wrote: > > There's some config you need to do on the wrapping filter to get it to > chose which attribute to read from. Did you do that? > > > On Fri, May 14, 2010 at 3:08 PM, Acevedo User <[email protected] < > http://[email protected]> > wrote: > > Ok I got it to a point where cas server authenticates using ldap. The CAS > client webapp directs to CAS and then the user can authenticate. > > In my web app I can list the attributes: > > <code> > AttributePrincipal principal = (AttributePrincipal) > request.getUserPrincipal(); > > Map attributes = principal.getAttributes(); > > > if (attributes.size() > 0) { > > > out.println("You have " + attributes.size() + " attributes : <br/>"); > > Iterator keyIterator = attributes.keySet().iterator(); > > > while (keyIterator.hasNext()) { > > > Object key = keyIterator.next(); > > Object value = attributes.get(key); > > out.println("<b>" + key + "</b>" + " : " + value + "<br>"); > > } > > } else { > > out.println("You have no attributes set"); > > } > > </code> > > The problem I have now is using "request.isUserInRole" I can't get it to > match against roles. > > On 5/14/10 2:58 PM, "Marvin Addison" <[email protected] < > http://[email protected]> > wrote: > > >> What I would like to do is be able to specify a list of attributes to > >> return, when I am authenticating a user. Is there anything like that > >> available in CAS? > > > > Yes. You'll want to use the attribute release feature of CAS in > > conjunction with the SAML protocol. Two good CASUM wiki links: > > 1. http://www.ja-sig.org/wiki/display/CASUM/Attributes > > 2. http://www.ja-sig.org/wiki/display/CASUM/SAML+1.1 > > > > M > > Emilio S. Acevedo > Enterprise Software Developer > Virginia's Community Colleges > 1-804-423-6758 > > > -- > You are currently subscribed to [email protected] < > http://[email protected]> as: [email protected] < > http://[email protected]> > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > Emilio S. Acevedo > Enterprise Software Developer > Virginia's Community Colleges > 1-804-423-6758 > > > Emilio S. Acevedo > Enterprise Software Developer > Virginia's Community Colleges > 1-804-423-6758 > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
