Baber and Raj,
Yes I did
make the change that Baber referred to. In Provo we were moving very fast and the diagram was evolving quickly. The
current architecture http://spwiki.editme.com/ArchitectureM4
does reflect my latest, best understanding.
I have not
yet been able to split out as a single unit these three: {Matcher, Digital Identity
Selector UI support and H-Tag Manager} and make them their own layer above what
is currently drawn in as the API. I agree vehemently that if things can be
cleanly separated and split out, they should be. As these components come into
more focus we’ll be able to see more clearly if and where the cut can be
made.
-Paul
-----Original Message-----
From: Nataraj Nagaratnam
[mailto:natarajn@xxxxxxxxxx]
Sent: Saturday, April
01, 2006 8:01 PM
To: Baber Amin
Cc: Anthony Nadalin; Duane Buss;
Dale Olds; higgins-dev@xxxxxxxxxxx; Igor Tsinman; Jan Camenisch; John Calcote;
Jim Sermersheim; Juan Carlos Luciani; 'Mary Ruddy'; John Merrells; Michael
McIntosh; Paul Trevithick; Pat Felsted; Tom Doman; Valery Kokhan
Subject: Re: M4 Architecture
Thanks for bringing this to attention/discussion,
Baber. I didn't realize this change ...
One
liner is my view is -- IdAS is the API, CPI is the SPI.
IdAS
is a fundamental concept and important. That is what applications (including
STS, etc) will know and use .. for those who are not identity provider savvy,
all they need to know is the IdAS. If collaboration sites, transaction
applications, need to use Higgins and they ask us what to do .. then we
tell them that the programming model - IdAS is what you need to know
about. They do not need to worry about context providers. For those site
providers who need to participate in a given identity metasystem, then CPI is a
way for them to plug into that system. Thus, in a framework provider model ...
I see IdAS as the "API" that others (applications including
STS, or other apps that need identity info, etc) can talk to. CPI is the
pluggable "SPI" that allows providers to be plugged into a metasystem
and thus accesible through an IdAS.
-Raj
ps:
i am using the term metasystem loosely here ;) .. to get the point across about
various contexts can be accessed through a system where those contexts are
'registered' in some sense.
|
"Baber Amin"
<baber@xxxxxxxxxx>
04/01/2006 07:17 PM
|
|
To
|
<higgins-dev@xxxxxxxxxxx>, "Tom
Doman" <TDoman@xxxxxxxxxx>, Anthony Nadalin/Austin/IBM@IBMUS
|
|
cc
|
"Duane Buss"
<DBuss@xxxxxxxxxx>, "Dale Olds" <DOlds@xxxxxxxxxx>,
"John Calcote" <JCALCOTE@xxxxxxxxxx>, "Jim
Sermersheim" <JIMSE@xxxxxxxxxx>, "Juan Carlos Luciani"
<JLUCIANI@xxxxxxxxxx>, "Pat Felsted"
<PFELSTED@xxxxxxxxxx>, "Igor Tsinman"
<igor@xxxxxxxxxxxxx>, "Valery Kokhan"
<valery@xxxxxxxxxxxxx>, "'Mary Ruddy'"
<mary@xxxxxxxxxxxxxxxxx>, "Paul Trevithick"
<paul@xxxxxxxxxxxxxxxxx>, "John Merrells"
<merrells@xxxxxxxx>, Michael McIntosh/Watson/IBM@IBMUS, Nataraj
Nagaratnam/Raleigh/IBM@IBMUS, "Jan Camenisch" <jca@xxxxxxxxxxxxxx>
|
|
Subject
|
M4 Architecture
|
|
Hi
Folks, the picture at the URL below has renamed IDAS to Context
Provider Interface. They might perform the
same function, but I feel
that we need to have IDAS with a very thin CPI
layer under it for the
context providers to plug into.
I see IDAS as a major Higgins component to be used
on back-end services
where we won't need anything above it. This
is where IDAS and Higgins
act as a identity normalization layer.
Having just a CPI there feels
empty. Even in the M4 picture, we see the
top of CPI talking to STS.
Since an STS is not a context provider it should
not be talking to that
interface, the top of the CPI should be IDAS.
Do you agree Paul?
Cheers
-Baber
http://spwiki.editme.com/ArchitectureM4
[attachment "higgins web integration
060315_1.JPG" deleted by Nataraj Nagaratnam/Raleigh/IBM]
|
