Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] Proposed change to IdAS

higgins-dev-bounces@xxxxxxxxxxx wrote on 11/29/2006 08:44:30 PM:

> Shouldn't cause any problems for anyone.  Regardless of the 
> idiosyncracy of JNDI and operational attributes, it was discussed 
> long ago that we'd want the ability to limit what attributes come 
> back for a given DigitalSubject, especially given that some 
> DigitalSubject may be composed of thousands of attributes.  Why 
> waste the time and memory space if we're only interested in a very 
> small and known number of them as is the case with the STS.

I think your reasoning makes sense if you assume that DigitalSubjects are 
created in a way that forces them to hold/cache all of their attributes.
An alternative would be to have the DigitalSubject own a connection thru 
the CP and fetch attributes on each get.
 
> 
> Tom
> 
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 11/29/2006 4:59 PM >>>
> While integrating code for the demo, we found that we needed to 
> allow an IdAS consumer to specify a list of attributes to fetch when
> calling IContext.getDigitalSubject.
> 
> As it turns out, the JNDI provider requires certain types of 
> attributes (in LDAP called "operational attributes") to be fetched 
> if asked for by name.  There's no way (with JNDI) to fetch "all 
> operational attributes".
> 
> So locally, I've added IContext.getSubject(String cuid, 
> Iterable<URI> attrSelectionList) where attrSelectionList is a list 
> of attribute types that the consumer expects to read from the 
> resulting IDigitalSubject.  I just wanted to see if this causes any 
> problems before I committed it.
> 
> Jim
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev



Back to the top