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
