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
