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
