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
