>>>>> "Alan" == Alan Buxey <[log in to unmask]> writes:

    Alan>    I just don't get the bit about the 'realm getting back to
    Alan> the RP. There

so, IDP a chooses foobar as its random string.

It gets to RP a and a CUI of foobar is granted access say to some
sensitive functions on the RP.

It's important that something in the system make sure that idp b is not
permitted to claim foobar as its random string and get the same
privileges.

We're dealing with existing applications with moonshot; we cannot in
general change the application to remember the IDP realm associated with
an identifier.
Even if we could, people will screw up that check.
Applications expect to be able to make authorization decisions by
matching a single identifier against an ACL.

Here are solutions we have:

1) Modify all the applications.
That goes against one of our project goals.

2) Have a database near the RP that remembers which IDP a particular
CUI-like string comes from.  If the same string comes from another IDP
turn it into an access reject.
Such databases require state at something that is reasonably close to
stateless and that's bad.

3) Map the attribute near the RP.  That is, we receive some string like
foobar and turn it into foobar@idp_a

4) Generate a scoped attribute and check it near the RP.  That is idp a
generates foobar@idp_a and we make sure the string ends in @idp_a near
the RP.

Option 4 avoids proxies transforming attributes and seems to be easiest
to implement.

--Sam