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</fil
ter-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/m
> ain/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.CredentialsToLDAPAttributePrinc
>> ipalResolver"> <!-- The Principal resolver form the
>> credentials --> <property
>> name="credentialsToPrincipalResolver"> <bean
>> class="org.jasig.cas.authentication.principal.UsernamePasswordCredentialsToPr
>> incipalResolver" /> </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.HttpBasedSer
>> viceCredentialsToPrincipalResolver" />--> </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.HttpBasedServiceCredentia
>> lsAuthenticationHandler" 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.BindAuthenti
>> cator"> <constructor-arg ref="contextSource"/> <property name="userSearch"
>> ref="userSearch" /> </bean> </constructor-arg> <constructor-arg> <bean
>> class="org.springframework.security.ldap.populator.DefaultLdapAuthoritiesPopu
>> lator"> <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
