Thanks Tom.  

That looks like just the ticket (pardon the pun).  Hopefully, I can
incorporate that without too much trouble.

Geoff 

-----Original Message-----
From: Tom O'Neill [mailto:[email protected]] 
Sent: Tuesday, July 28, 2015 10:41 AM
To: [email protected]
Subject: RE: [cas-user] Attribute repository with multiple different sources

Geoff,

In the past with CAS 3.5.x I've used a merging attribute repository to
implement the behavior you are describing.
Each attribute repository can have its own search filter and there are
multiple strategies for how merging occurs when the attribute is available
from both sources.
The options for attribute release in CAS 4 are outlined in the github hosted
documentation:
        http://jasig.github.io/cas/4.0.x/integration/Attribute-Release.html

Hopefully that helps!

Thanks,

    Tom O'Neill
    Senior Consultant
    Strata Information Group

-----Original Message-----
From: Whittaker, Geoffrey [mailto:[email protected]]
Sent: Monday, July 27, 2015 11:20 AM
To: [email protected]
Subject: RE: [cas-user] Attribute repository with multiple different sources

I'd thought of that, but was worried how cas might react.  I'll do a test
build of that and see what happens.  I'm Also looking at the possibility of
adding the CN field to the second LDAP source.  

Geoff 

-----Original Message-----
From: Waldbieser, Carl [mailto:[email protected]]
Sent: Monday, July 27, 2015 9:23 AM
To: [email protected]
Subject: Re: [cas-user] Attribute repository with multiple different sources

Geoffrey,

Can you just map both 'uid' and 'cn' to 'UDC_IDENTIFIER'?  I could see a
potential issue with that if one directory supports both attributes and
there would be some potential ambiguity about which attribute would actually
end up being mapped.

I am guessing there is likely to be a solution to this baked into CAS.

You can also handle this by manipulating the LDAP response before it reaches
CAS with an LDAP proxy.  Specifically, you could convert the 'cn' attribute
in the response of LDAP2 to 'uid'.
I wrote a blurb on setting up an LDAP proxy [1], though I am just noticing
that my code formatting was messed up.  A well-formatted code example can be
found on github[2].
This is a more heavy-handed approach, so I'd probably try experimenting with
CAS attribute mappings first.
  

Thanks,
Carl Waldbieser

[1] https://lifeonlayer7.wordpress.com/2015/07/18/ldap-proxy/
[2]
https://github.com/twisted/ldaptor/blob/master/docs/source/cookbook/ldap-pro
xy.rst

----- Original Message -----
From: "Geoffrey Whittaker" <[email protected]>
To: [email protected]
Sent: Monday, July 27, 2015 7:36:19 AM
Subject: [cas-user] Attribute repository with multiple different sources

I have CAS4 with two LDAP Auth Handlers.  The first is pointed at my local
Active Directory (LDAP1) which has my Employees, Staff, Faculty, etc..  The
second is pointed at another LDAP server (ldap2) which contains alumni,
parents, and other 'special' people.  

 

Currently, if the search of LDAP1 fails CAS falls through to LDAP2.  In the
past, it's been sufficient for those people only in LDAP2 to merely
authenticate.  Now, I need to get an attribute from that directory and map
it to the attribute map to the same field that LDAP1 would use.  The problem
is the name of the fields is different.  In LDAP1 the field is 'cn' in LDAP2
the field is 'uid'.  I somehow have to get that value from into a custom
Attribute field we called UDC_IDENTIFIER regardless of the directory.

 

Can I have more than one attribute repository, and if can someone point to
an example config?

 

 

 

Am I making this too complicated?  Is there another way to handle this?  

 

Thanks


--
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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to