Here is a snippet of the client Spring configuration file(service
configuration, reffer the ROLES as the issued attribute):
<!--
Handles the CAS ticket processing.
-->
<bean id="casAuthenticationProvider"
class="org.springframework.security.cas.authentication.CasAuthenticationProvider"
>
<property name="authenticationUserDetailsService">
<bean
class="org.springframework.security.cas.userdetails.GrantedAuthorityFromAssertionAttributesUserDetailsService">
<constructor-arg name="attributes" >
<list>
<value>ROLES</value>
</list>
</constructor-arg>
</bean>
</property>
<property name="serviceProperties" ref="serviceProperties"></property>
<property name="ticketValidator">
<bean class="com.shunra.cas.Saml11TicketValidator" >
<constructor-arg index="0" value="https://
${cas.server.host}:${cas.server.port}/${cas.server.name}"></constructor-arg>
</bean>
</property>
<property name="key" value="${app.name}"></property>
</bean>
On Mon, Feb 18, 2013 at 10:02 PM, Andrew Chandler <[email protected]> wrote:
> Almost, I'm being kind of dense I think - and I apologize for that. I'm
> already using this functionality in the deployerConfigContext.xml :
> <bean id="attributeRepository"
>
> class="org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao">
> <property name="baseDN" value="dc=williams,dc=com"/>
> <property name="contextSource" ref="contextSource"/>
> <property name="requireAllQueryAttributes" value="true"/>
> <property name="ldapTemplate" ref="ldapTemplate" />
> <property name="queryAttributeMapping">
> <map>
> <entry key="username" value="sAMAccountName"/>
> <!--<entry key="username" value="uid"/>-->
> </map>
> </property>
> <property name="resultAttributeMapping">
> <map>
> <!-- Mapping between LDAP attributes (key) and Principal's
> (value) -->
> <entry value="CN" key="cn" />
> <entry value="DN" key="distinguishedName" />
> <entry value="Groups" key="memberOf" />
> </map>
> </property>
> </bean>
>
>
> This coupled with the fact that CAS is running in open mode (no services
> registered at all so that any service can use it) seems to get back to a
> test client the List of Groups. ( I included a snippet from a jsp
> output on a tutorial client in a previous message showing they all come
> back). Then on the client side I'm using
> "org.springframework.security.cas.userdetails.GrantedAuthorityFromAssertionAttributesUserDetailsService"
> to theoretically map those groups to become Authorities. At this point
> its ALMOST working. That tutorial JSP shows the Groups can be returned to
> the client but my real application when I step through
> grantedAuthority.... doesn't see them. Almost thinking I might have a
> protocol mismatch. The tutorial client is using the
> Saml11TicketValidationFilter. I think my real app is using
> Cas20ServiceTicketValidator which I going to look at after my meeting.
>
>
> On Mon, Feb 18, 2013 at 12:08 PM, Modi Tamam <[email protected]> wrote:
>
>>
>> 1. In order to add additional attributes to your server response, you
>> should add your attributes DAO, it's an implementation of
>> BasePersonAttributeDao(the code that I paste on the previouse mail was a
>> part of it, all other methods are not required if you are using
>> the UsernamePasswordCredentialsToPrincipalResolver class)
>> 2. In order to include those attributes with your response, you
>> should add the allowed attributes element to your serviceRegistryDAO, edit
>> the deployConfiguration.xml file as follow: <bean
>> id="serviceRegistryDao"
>> class="org.jasig.cas.services.InMemoryServiceRegistryDaoImpl">
>> <property name="registeredServices">
>> <list>
>> <bean
>> class="org.jasig.cas.services.RegexRegisteredService">
>> .....
>> .....
>> *<property name="allowedAttributes">*
>> * <list>*
>> * <value>ROLES</value>*
>> * </list> *
>> * </property>*
>> </bean>
>> </list>
>> </property>
>> </bean>
>> 3. Now, at this point your response should include your attributes
>> 4. Now, you should retrieve them on your client and parse the
>> response into your user details object. The parsing depends on what
>> protocol are you using (SAML?)
>>
>>
>> Did I answer your question?
>>
>>
>>
>>
>> On Mon, Feb 18, 2013 at 6:17 PM, Andrew Chandler <[email protected]>wrote:
>>
>>> Sorry I think I got sidetracked. My question is:
>>>
>>> 1: Doesn't GrantedAuthorityFromAssertionAttributesUserDetailsService do
>>> basically that already, just on the client side instead of the server?
>>>
>>> 2: Am I wrong - should that class actually be configured in to the Cas
>>> Server instead? (I've been trying to chain it in on the client side and
>>> maybe that's my problem)
>>>
>>>
>>>
>>> On Mon, Feb 18, 2013 at 9:59 AM, Modi Tamam <[email protected]>wrote:
>>>
>>>> So, what is your question?
>>>>
>>>>
>>>> On Mon, Feb 18, 2013 at 5:25 PM, Andrew Chandler <[email protected]>wrote:
>>>>
>>>>> Thanks - I appreciate the pointer. I suspect I have to clean up my
>>>>> project - all my testing has left a lot of dead ends I may need to start
>>>>> over. Part of my problem is we are making several web apps with both
>>>>> UI's
>>>>> and restful web services. We're trying to stay on the annotation side -
>>>>> we had pretty much everything working when I was just using straight
>>>>> spring-security with Active Directory - it's been the casifying of my
>>>>> projects that's gotten me twisted up. I've got the CAS server
>>>>> authenticating and returning attributes properly - I can verify that with
>>>>> a
>>>>> simple CAS test web app that causes me to authenticate and then returns
>>>>> the user details. however that one doesn't use
>>>>> spring-security-context.xml --- it strictly uses web.xml to set everything
>>>>> up. Part of my problem seems to be not knowing which things are required
>>>>> in web.xml anymore and which things are best over in the
>>>>> application-context.xml or the security-context.xml.
>>>>>
>>>>> However if I'm reading your snippet correctly above the purpose of
>>>>> that is to take the Groups List and turn them into a granted authority?
>>>>> If so that is what I want.
>>>>>
>>>>> Here is a sample of what the test webapp client is getting back:
>>>>>
>>>>> request.getRemoteUser() = SChandle
>>>>> request.getUserPrincipal() = SChandle
>>>>>
>>>>> The context root name of this application is /testApp1 Mon Feb 18
>>>>> 09:22:43 CST 2013
>>>>>
>>>>>
>>>>> Released AttributesGroups is a List:
>>>>> CN=LiveLinkUserList,OU=DynamicGroups,DC=WILLIAMS,DC=com
>>>>> CN=SSO_AtlasProd,OU=SecurityGroups,DC=WILLIAMS,DC=com
>>>>> CN=mmart_admin_Dev,OU=SecurityGroups,DC=WILLIAMS,DC=com
>>>>> CN=mmart_admin,OU=SecurityGroups,DC=WILLIAMS,DC=com
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Feb 17, 2013 at 11:37 PM, Modi Tamam <[email protected]>wrote:
>>>>>
>>>>>> What you should is:
>>>>>>
>>>>>> 1. implement your own *BasePersonAttributeDao.*
>>>>>> 2. Override the getPerson(String uid) method.
>>>>>> 3. configure the deployerConfigContext to use the above
>>>>>> implementation.
>>>>>>
>>>>>> Here is a snippet of an example:
>>>>>> @Override
>>>>>> public IPersonAttributes getPerson(String uid) {
>>>>>> UserDetails userDetails =
>>>>>> userDetailsService.loadUserByUsername(uid);
>>>>>> Collection<? extends GrantedAuthority> authorities =
>>>>>> userDetails.getAuthorities();
>>>>>> if (!CollectionUtils.isEmpty(authorities)) {
>>>>>> Map<String, List<Object>> attributes = new LinkedHashMap<String,
>>>>>> List<Object>>();
>>>>>> List<Object> authoritiesLst = new LinkedList<Object>();
>>>>>> attributes.put("ROLES", authoritiesLst);
>>>>>> for (GrantedAuthority authority : authorities) {
>>>>>> authoritiesLst.add(authority.getAuthority());
>>>>>> }
>>>>>> IPersonAttributes retVal = new NamedPersonImpl(uid, attributes);
>>>>>> return retVal;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The user details service is my attributes repository, you can replcae
>>>>>> it with any other repository.
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 18, 2013 at 4:56 AM, Andrew Chandler
>>>>>> <[email protected]>wrote:
>>>>>>
>>>>>>> I thought it would but I must be configuring it wrong. The
>>>>>>> attributes are coming in as a list of groups, I need them to be roles,
>>>>>>> or
>>>>>>> testable as roles in spring, my constructor for the bean you mention
>>>>>>> had
>>>>>>> "attributes" for a parameter, I'm going to try switching that to groups
>>>>>>> On Feb 17, 2013 8:17 PM, "Scott Battaglia" <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> I haven't tried in a while but doesn't this do what you want?
>>>>>>>>
>>>>>>>> http://static.springsource.org/spring-security/site/docs/3.1.x/apidocs/org/springframework/security/cas/userdetails/GrantedAuthorityFromAssertionAttributesUserDetailsService.html
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Scott
>>>>>>>>
>>>>>>>> On Fri, Feb 15, 2013 at 5:09 PM, Andrew Chandler <[email protected]
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> I'm hoping someone can help me with this before I go bald.
>>>>>>>>>
>>>>>>>>> I've successfully followed the tutorials and got CAS server up and
>>>>>>>>> running on Tomcat on SSL. For now all web applications are hosted
>>>>>>>>> in this
>>>>>>>>> single Tomcat instance. Cas is configured to authenticate against
>>>>>>>>> Active Directory via the LDAP Bind process (not fastbind). I also
>>>>>>>>> have it
>>>>>>>>> configured to use the attributeRepository
>>>>>>>>> org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao
>>>>>>>>>
>>>>>>>>> Following a different tutorial I setup a simple jsp client webapp
>>>>>>>>> that showes the information it got back from CAS and I see all my AD
>>>>>>>>> groups
>>>>>>>>> in the attributes that were placed on the principals.
>>>>>>>>>
>>>>>>>>> What I am trying to do in my Spring based Web App is reproduce
>>>>>>>>> what I successfully did when I had that single webapp authenticating
>>>>>>>>> using
>>>>>>>>> spring security to Active Directory. The groups became authorities
>>>>>>>>> and
>>>>>>>>> were used in filtering access. My problem is the only client
>>>>>>>>> examples
>>>>>>>>> I've seen to access the attributes returned from CAS weren't really
>>>>>>>>> participating in the spring authentication process. I'm looking for
>>>>>>>>> a
>>>>>>>>> good, simple example using current versions of spring security (not
>>>>>>>>> older
>>>>>>>>> 2.x stuff) that will take the authentication I get back from CAS and
>>>>>>>>> use
>>>>>>>>> the "Groups" properties and turn those into roles during the security
>>>>>>>>> filtering process so that the user can access protected resources.
>>>>>>>>> Any
>>>>>>>>> info would help.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>>
>>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards
>>>>>> Mordechai Tamam
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards
>>>> Mordechai Tamam
>>>>
>>>> --
>>>> 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
>>>
>>>
>>
>>
>> --
>> Best Regards
>> Mordechai Tamam
>>
>> --
>> 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
>
>
--
Best Regards
Mordechai Tamam
--
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
