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
