Robert, Thanks for the link. I'd even suggest that you formulate a pull request against person directory's repo. Seems like this is a thing that should be included and released.
From: Robert Oschwald [mailto:[email protected]] Sent: Wednesday, April 23, 2014 12:48 AM To: [email protected] Subject: Re: [cas-user] populating attributes from same source as authentication We released the DirectMappedPersonAttributeDao as well as a sample WS Authentication Handler under the Apache License. See https://github.com/robertoschwald/jasig-cas-examples-robertoschwald Best, Robert Am 10.04.2014 um 16:41 schrieb Stefan Paetow <[email protected]>: Robert, Would you be amenable to releasing that component as open-source? We'd be interested (at Diamond Light Source and Janet) because we also receive a large number of attributes after authentication (via RADIUS and/or SAML). With Regards Stefan On 8 April 2014 17:21, Robert Oschwald <[email protected]> wrote: 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 -- 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
