Consequently ...
Alice wants her friend Bob to be able to view her current location as she moves around the city. After receiving the invitation and consenting, Bob gets added to Alice's People Service, and a number of shared identifiers are established between various providers.
Critically, Alice's geolocation provider (AGP) gets an identifier for Bob against which it can assign appropriate access privileges (maybe Alice set things up so that Bob can see her location only during the work day). When Bob browser SSO's into the AGP from his own IDP, AGP is able to recognize the asserted identifier as somebody that is allowed to see Alice's location and so can give Bob a nice map interface. Importantly, that may be all the AGP knows about Bob.
For access to such browser-based resources, it's pretty straightforward. However, if Bob wanted to access Alice's location from within his own geolocation provider (BGP) rather than visiting AGP in his browser, things get trickier.
BGP will send a request to AGP for Alice's geolocation so that the data can be integrated into its own application, and then likely shown to Bob. The Liberty Alliance SOAP Binding allows for such a request from BGP to AGP to be sent, logically:
Hello AGP, this is BGP asking on behalf of 'Bob', what is the current location of 'Alice'?Nb: 'Bob' and 'Alice' in the above will generally be appropriate identifiers (possibly encrypted so that BGP can't see them) for the two users that AGP will either be able to recognize or be able to map into identifiers that it can.
Everything seems peachy keen - as before AGP determines if Bob is allowed to see Alice's location (and perhaps whether BGP is allowed to ask on Bob's behalf), and then either responds with the data or declines.
There is a missing piece in the above however. How does BGP know that Alice has granted Bob permission to see her location? More fundamentally, how does BGP even know Alice exists and that Bob knows her?
The Liberty Alliance People Service addresses these questions by allowing (but not stipulating), that, in addition to Bob being added to Alice's PS, Alice can be added to Bob's PS - the two People Service lists are, in a sense, mirror images of the other.
If this happened when Bob was added to Alice's PS at the start, then Alice would also be added to Bob's PS list. When Bob subsequently visits BGP, that application can query Bob's People Service and will see Alice in the list. From there BGP can obtain the appropriate identifiers and service endpoints so that it can compose the above message.
The sequence by which BGP asks AGP for Alice's data is something like
1) Bob SSOs into BGP from his IDP
2) BGP discovers Bob's PS
3) BGP queries Bob's PS for list of friends
4) BGP requests an identity token for Alice
5) Bob's PS does some work behind the scenes to get an identity token for Alice
6) Bob's PS returns the identity token to BGP
7) BGP uses the identity token to query Alice's Discovery Service for Alice's Geolocation provider
8) Alice's DS returns the location of AGP and an encrypted identifier to use for Alice there
9) BGP sends above message to AGP
10) AGP returns Alice's location to BGP
11) BGP shows Alice's location to Bob
12) Alice and Bob decide to, yet again, 'take a break'.
No comments:
Post a Comment