[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] IdAS: Specifying attributes up front
|
Jim,
I think we also need to discuss whether the IDigitalSubject (IDS) points
to a dynamic version of the attributes or is it expected a static copy
made at get-time.
What happens when an IDS is used to write attributes to an entry? Is there
some sort of flush to backing store required?
Seems like we are optimizing for read in a lot of cases and need to start
thinking about write.
Thanks,
Mike
higgins-dev-bounces@xxxxxxxxxxx wrote on 02/23/2007 09:40:30 PM:
> <Changed subject text>
> We also need to decide what the semantics are when the IdAS user
> specifies the attributes up front (getlSubject(s)). Is it merely a
> hint, and the caller may or may not ask for additional attributes
> later (IDigitalSubject.getAttribute(URI)), or is it a contract, and
> the CP is not expected to return any attributes not in the list?
> (note that by passing a null, the caller specifies that all
> attributes may be read)
>
> The former choice prevents CPs which hit the wire to fetch data from
> multiple wire hits, the latter choice offers more freedom. If we
> pick the latter choice, then we have to decide what it means to call
> IDigitalSubject.getAttributes() -- go fetch them all, or only the
> ones initially asked for?
>
> Jim
>
>
> >>> "Tom Doman" <TDoman@xxxxxxxxxx> 2/23/07 5:30 PM >>>
> Okay well I will say that if an IdAS consumer can specify the attributes
> that are desired up front, that should be optimal for all CPs. Even if
> the CP is obliged to get all attributes anyway. That's why I'm
comfortable
> with the up front list of claims as long as it's not an undue
architectural
> burden on you.
>
> Regardless, with the mapping CP that we've recently completed, we'd
> be able to create a PDP that adds any attribute we want to be always
> requested, LDAP "operational" or not. That coupled with a
getDigitalSubject
> that gets "all" attributes would achieve the same result, though, for
> any CP, returning "all" attributes when only some are required will be
> less efficient, at least from the wire perspective.
>
> At any rate, as soon as we figure out where the registry is going, the
> mapping CP will be ready for prime time and if it's use described above
> could help make your architecture more straight forward, let me know
> and we'll create a configuration which accommodate you.
>
> Tom
>
> >>> Michael McIntosh <mikemci@xxxxxxxxxx> 02/23/07 5:02 PM >>>
> higgins-dev-bounces@xxxxxxxxxxx wrote on 02/23/2007 06:37:42 PM:
>
> > Okay, thanks. Two questions:
> >
> > 1. Should we allow the JNDI CP to be configured to always get a
> > certain set of operational attributes or some other change that
> > would better accommodate what you're trying to do? I'm not sure how
> > other CPs may end up nor that getting all attributes plus an
> > operational set every time is the most efficient approach but for
> > the STS scenario, might that be the best?
>
> I am not sure what is best - "operational" attributes are an LDAP
concept.
> Would prefer to not have to bind the generic CP consumer code to that.
But
> at the same time would like to not do something that is sub-optimal when
> used with LDAP.
>
> > 2. Outside of the scope of #1, is there some other IdAS change that
> > would help put the construction\configuration of the CP nearer or
> > exactly where it's needed to eliminate the hack-ish work around?
>
> Not really.
>
> >
> > Tom
> >
> > >>> Michael McIntosh <mikemci@xxxxxxxxxx> 02/23/07 2:54 PM >>>
> > The pressing need is this...
> >
> > Until recently, the STS framework would process the WS-Security header
> and
> > construct a DigitalSubject which it would pass to the token provider
> which
> > would pull attributes from it for claims.
> > Due to the fact that the LDAP/JNDI CP requires the set of claims to be
> > specified when getDigitalSubject is called, the getDigitalSubject call
> has
> > had to be moved to where the claims processing code is (the token
> > provider).
> > The IdAS instance was not being passed from where it is contructed and
> > configured (framework), to where it is now needed (providers). In
order
> to
> > work around this I've had to do something very hack-ish, which I can
> > remove once I can just get the same instance from anywhere.
> >
> > Thanks,
> > Mike
> >
> > higgins-dev-bounces@xxxxxxxxxxx wrote on 02/23/2007 11:04:40 AM:
> >
> > > This all sounds fine to me, I would just like to understand the
> > > pressing need to make this happen sooner than later especially in
> > > light of the refactoring we're currently engaged in. Not that there
> > > isn't a pressing need nor that I have a problem with an incremental
> > > change, I'd just like to know what it is.
> > >
> > > Tom
> > >
> > > >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 02/22/07 11:01 PM >>>
> > > ok, yeah -- I was going to ask if you thought it important to move
> > > on this with the current IdAS registry model or if we could wait for
> > > the refactoring that is taking place (which may take some time
still).
> > >
> > > It sounds like you have a pressing need to make this happen sooner
> > > than later, so barring any dissent, let's say this:
> > >
> > > We plan to make the constructors of IdASRegistry non-public, and at
> > > the same time add a static getInstance() method which will be used
> > > to access the registry as a singleton.
> > >
> > > I'll add the getInstance() method tomorrow (Feb 22). I'll make the
> > > constructors non-public on Monday (Feb 25).
> > >
> > > Note that this does not preclude us from implementing any of the
> > > other items below in the future, but for now we'd like to at least
> > > make this one incremental change.
> > >
> > > Jim
> > >
> > > >>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/22/07 6:59 PM >>>
> > > Can we reach consensus on this quickly and start the clock on the
> > > interface change notice period ASAP?
> > >
> > > Thanks,
> > > Mike
> > >
> > > higgins-dev-bounces@xxxxxxxxxxx wrote on 02/22/2007 08:24:39 PM:
> > >
> > > > I agree. And beyond this, we've been thinking that it should also
> > > > produce ContextFactories as singleton's as well. In respect to
our
> > > > ongoing registry discussions, it would actually hold a map where
the
> > > > key is an identifier (which represents a factory+factoryConfig),
and
> > > > the value would be the factory.
> > > >
> > > > Also, I wonder if this class should even be called a "registry".
It
> > > > feels more like a factory producer to me.
> > > >
> > > > Jim
> > > >
> > > > >>> Michael McIntosh <mikemci@xxxxxxxxxx> 2/22/07 6:14 PM >>>
> > > > Can we make the IdASRegistry a singleton by creating a getInstance
> > > method?
> > > > Can anyone think of any reason why we'd want more than one
> > IdASRegistry
> > > > instance?
> > > >
> > > > Thanks,
> > > > Mike
> > > > _______________________________________________
> > > > higgins-dev mailing list
> > > > higgins-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > > > _______________________________________________
> > > > higgins-dev mailing list
> > > > higgins-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > >
> > > _______________________________________________
> > > higgins-dev mailing list
> > > higgins-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > > _______________________________________________
> > > higgins-dev mailing list
> > > higgins-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
