Finished my own implementation MappedPersonAttributeDao (which extends AbstractQueryPersonAttributeDao). This AttributeDao is backed by a ConcurrentHashMap with an public void addAttributes(String netid, Map<String, List<Object>> attributes) method, which gets called from my WebserviceAuthenticationHandler to update principals attributes in authenticateUsernamePasswordInternal().
The map entries are short-term cached, as principals entry gets removed on a serviceValidate call from the attributeMap. Therefore I also define the possibleUserAttributeNames Set in the deployerConfigContext bean config (so I can set attributes on a per-service base in the Service Manager application). Works pretty well so far in first tests. Attributes get serialized in the ticketRegistry TGT store as they should. Only thing I figured out is the Principal vs. IPersonAttributes. Principal defines attributes as Map<String,Object> whereas IPersonAttributes are defined as Map<String,List<Object>>. The webserviceClient returns a SimplePrincipal in WebserviceAuthenticationHandler, therefore I transform Map<String,Object> before calling MappedPersonAttributeDao.addAttributes(String netid, Map<String, List<Object>> attributes) Sounds a bit inconsistent, but I know that I’m one of the few people who fill the attributes in the authentication phase. Now I have a solution which is lightweight and cheap in terms of request roundtrips, as the attributes are provided from the same single authentication SOAP request. Robert Am 07.04.2014 um 22:11 schrieb Daniel Ellentuck <[email protected]>: > Hi Robert, Misagh, et. al., > > I think it depends on what you mean by "populate attributes directly." > > If your authentication call can store the attributes of interest somewhere > that a personAttributeDao can retrieve them from (a database table, a > distributed cache, etc.), then the dao can make them available to the > attributeRepository. I've done this kind of thing in the past and it's pretty > simple. It's maybe not "populate attributes directly" but it could save you > that second web service call. > > Dan > > Dan Ellentuck > > > > On Mon, Apr 7, 2014 at 3:14 PM, Misagh Moayyed <[email protected]> wrote: > I doubt it. You'd have to build one that talks to the WS. > > > -----Original Message----- > > From: Robert Oschwald [mailto:[email protected]] > > Sent: Monday, April 07, 2014 10:38 AM > > To: [email protected] > > Subject: [cas-user] populating attributes from same source as > authentication > > > > I'm wondering if it is possible to populate attributes directly from the > > authentication source without performing a 2nd call. > > I already receive the additional attributes from a web service as a > response > > to the authentication call. > > > > Is there a special attributeRespository available which I can fill > during > > authentication? > > > > > > Robert > > > > > > > > > > -- > > 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 -- 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
