...
This
...
is
...
a
...
replacement
...
for
...
the
...
...
topic,
...
which
...
delved
...
into
...
an
...
obsolete
...
draft
...
document
...
I
...
worked
...
on
...
to
...
try
...
and
...
understand
...
the
...
technical
...
requirements
...
for
...
applying
...
SAML
...
2.0
...
to
...
portals,
...
meta-search,
...
web
...
services,
...
and
...
other
...
multi-tier
...
use
...
cases.
...
The
...
general
...
problem
...
space
...
is
...
one
...
of
...
web
...
services
...
(thus
...
the
...
topic
...
change
...
),
...
although
...
a
...
lot
...
of
...
the
...
basic
...
pieces
...
should
...
be
...
applicable
...
in
...
some
...
fashion
...
to
...
other
...
kinds
...
of
...
applications
...
in
...
the
...
future.
...
But
...
initially,
...
the
...
priority
...
seems
...
to
...
be
...
how
...
to
...
extend
...
the
...
"Shibboleth
...
model"
...
into
...
a
...
web
...
services
...
environment.
...
At
...
this
...
stage,
...
the
...
Shibboleth
...
model
...
is
...
for
...
all
...
intents
...
and
...
purposes
...
SAML V2.0.
...
Right
...
now,
...
SAML V2.0
...
does
...
NOT
...
include
...
profiles
...
that
...
provide
...
complete
...
authentication
...
solutions
...
for
...
SOAP.
...
Neither
...
does
...
Shibboleth,
...
in
...
either
...
its
...
current
...
(1.3
...
)
...
or
...
next
...
(2.0
...
)
...
version,
...
provide
...
any
...
support
...
for
...
this.
...
If
...
that's
...
why
...
you're
...
here,
...
you
...
can
...
stop
...
reading
...
unless
...
you're
...
interested
...
in
...
reading
...
about
...
possibly
...
future
...
directions.
...
I
...
define
...
web
...
services
...
as
...
SOAP,
...
period.
...
The
...
name
...
is
...
lousy
...
(SOAP
...
has
...
nothing
...
to
...
do
...
with
...
the
...
web
...
),
...
but
...
it's
...
the
...
industry
...
term,
...
so
...
readers
...
can
...
make
...
whatever
...
internal
...
adjustments
...
they
...
find
...
appropriate.
...
Note
...
that
...
non-SOAP
...
services,
...
such
...
as
...
the
...
so-called
...
"REST"
...
model,
...
lack
...
any
...
inherent
...
ability
...
to
...
support
...
new
...
security
...
models
...
other
...
than
...
at
...
the
...
HTTP
...
layer.
...
That's
...
the
...
most
...
important
...
difference.
...
REST
...
assumes
...
security
...
is
...
a
...
non-factor,
...
or
...
that
...
HTTP
...
can
...
handle
...
it.
...
If
...
either
...
is
...
true
...
for
...
your
...
application,
...
you
...
don't
...
really
...
need
...
SAML
...
anyway.
...
That
...
said,
...
focusing
...
on
...
SOAP,
...
the
...
user's
...
client
...
itself
...
may
...
be
...
SOAP-capable,
...
servers
...
may
...
be
...
interacting
...
directly,
...
or
...
a
...
traditional
...
browser
...
client
...
may
...
be
...
invoking
...
a
...
service
...
that
...
is
...
invoking
...
SOAP
...
services
...
on
...
behalf
...
of
...
the
...
user.
...
I
...
believe
...
that
...
this
...
set
...
of
...
possibilities
...
adapts
...
itself
...
to
...
model
...
most
...
of
...
the
...
use
...
cases
...
in
...
the
...
general
...
space
...
of
...
portals
...
and
...
meta-search,
...
as
...
well
...
as
...
the
...
kinds
...
of
...
use
...
cases
...
directly
...
addressed
...
by
...
the
...
...
...
...
specs.
...
As
...
I
...
see
...
it,
...
there
...
are
...
four
...
basic
...
components
...
to
...
a
...
solution
...
here,
...
aside
...
from
...
SAML
...
2.0
...
itself
...
and
...
all
...
the
...
underlying
...
functionality
...
that's
...
already
...
somewhat
...
understood.
...
This
...
glosses
...
over
...
a
...
lot
...
of
...
the
...
details,
...
but
...
I'm
...
considering
...
issues
...
like
...
NameIdentifiers
...
and
...
attributes
...
to
...
be
...
out
...
of
...
scope.
...
They're
...
the
...
data
...
being
...
carried,
...
but
...
they
...
should
...
compose
...
with
...
the
...
new
...
mechanisms
...
in
...
whatever
...
manner
...
is
...
appropriate
...
for
...
the
...
privacy
...
and
...
security
...
necessary
...
for
...
the
...
application
...
in
...
question.
...
The
...
original
...
draft
...
identified
...
these
...
four
...
solution
...
components:
...
- Modeling
...
- SAML
...
- assertions
...
- that
...
- reflect
...
- "on
...
- behalf
...
- of"
...
- security
...
- semantics
...
- Integrating
...
- requests
...
- for
...
- such
...
- assertions
...
- with
...
- web
...
- SSO
...
- "Stand-alone"
...
- token
...
- service
...
- for
...
- obtaining
...
- assertions
...
- outside
...
- of
...
- web
...
- SSO
...
- Application
...
- profile
...
- for
...
- use
...
- of
...
- assertions
...
- to
...
- secure
...
- SOAP
...
- calls
...
Of
...
these
...
four,
...
all
...
but
...
the
...
second
...
are
...
addressed
...
by
...
portions
...
of
...
the
...
...
...
...
specs
...
(as
...
outlined
...
below
...
).
...
ID-WSF
...
also
...
adds
...
significant
...
pieces
...
that
...
may
...
become
...
important
...
in
...
the
...
future,
...
such
...
as
...
service
...
discovery,
...
which
...
I
...
ignored.
...
The
...
second
...
requirement
...
is
...
not
...
explicitly
...
addressed
...
in
...
ID-WSF,
...
but
...
can
...
be
...
implemented
...
with
...
a
...
small
...
SAML
...
2.0
...
extension
...
profile
...
if
...
it's
...
needed.
...
I
...
don't
...
believe
...
that
...
the
...
additional
...
complexity
...
due
...
to
...
the
...
generality
...
of
...
these
...
specs
...
justifies
...
spending
...
project
...
resources
...
implementing
...
proprietary
...
approaches
...
that
...
may
...
be
...
slightly
...
simpler
...
but
...
are
...
still
...
highly
...
complex
...
relative
...
to
...
the
...
usual
...
fall-back
...
solutions.
...
If
...
it's
...
justifiable
...
to
...
do
...
something
...
as
...
complex
...
as
...
what
...
I
...
originally
...
proposed,
...
the
...
added
...
benefit
...
of
...
a
...
commercial
...
standard
...
is
...
worth
...
a
...
small
...
increase
...
in
...
work.
...
To
...
help
...
in
...
understanding
...
how
...
the
...
ID-WSF
...
specs
...
map
...
to
...
the
...
solution
...
components
...
above,
...
I
...
suggest
...
referring
...
to
...
the
...
following,
...
and
...
the
...
...
Modeling Delegation
When services access other services on behalf of users, or other services, it's important to reflect the "presence" of both actors in the invocation. The LibertyWSFSecurity specs include a technique for expressing this in SAML V2.0 using the SubjectConfirmation element.
This technique has been "blessed" as being consistent with the SAML V2.0 Core specification in an errata that rewrites some of the language around the SubjectConfirmation element and the use of an embedded identifier. This avoids the need for communities to define their own syntax for expressing this.
SOAP Application Profile
The LibertyWSFSOAPBinding and LibertyWSFSecurity specs define a SOAP application profile. It's fairly extensive, but the core requirements are fairly simple. It doesn't constrain the use of WS-Security as much as I'd like, but that can be tightened up for particular applications.
SAML Token Service
The LibertyWSFAuthentication spec includes a SAML V2.0 profile that is referred to as a "token service". It was developed by me (Main.ScottCantor) and adapted to ID-WSF requirements, which also serves to tighten up the profile and provides more specifics on how to use it.
The token service is important to enable services to trade in old assertions for new ones, which is important when preserving privacy using pairwise NameIdentifiers or encrypted attributes. It's also important when not relying on LibertyWSFDiscovery to obtain assertions during the process of locating services.
Use Cases / Examples
As use cases are developed, they'll be compiled here along with examples on how they can be addressed with industry standards.
$ MetaSearch: Applications involving intermediary search services.
$ PerfSONAR: Network Monitoring Data Exchange projects.