Liberty People Service for Group-based Access Control

Allowing users to define access control for their online resources in terms of their online friends & colleagues was one of the key use-cases that drove the development of the Liberty Alliance's People Service. We recognized that often times a user will wish to define access rights against a group of such friends rather than each individually, e.g. 'Allow all members of the "Soccer Team" group to see my online calendar and allow all members of 'Coaching Staff' to add entries'.

In this scenario, Alice has defined access rules to some of her resources at aservice provider (SPa) based on membership in a 'Work Friends' group she maintains at her people service (PSa). Anybody who is in the group can see the page etc, anybody else can't.

Bob is a friend of Alice and she has previously both added him to her People Service as well as to the group in question. Now, when Bob appears at SPa and tries to access the resource in question, in order to enforce Alice's policy, SPa must determine if Bob is a member of the 'Work Friends' group.

The messages below (a mixture of SAML & Liberty WSF) give an idea of how this might work.

1. Bob shows up at SPa and tries to access the resource in question.

2. SPa asks 'Who are you?'.

3. Bob wants to use his identity provider account and so says 'Ask IDPb'.

4. SPa redirects Bob to IDPb with a SAML AuthnRequest message.

    <samlp:AuthnRequest
      ID="NTT7630E00861279F0ADC63E241D0926D0B"
      Version="2.0" IssueInstant="...">
      <saml:Issuer 
          format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://spa.com
      </saml:issuer>
      <samlp:NameIdpolicy 
         format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    </samlp:Nameidpolicy>
   <samlp:AuthnRequest>
 

5. IDPb authenticates Bob.

6. IDPb sends a SAML Response to SPa with a SAML AuthnStatement carrying a name identifier for Bob (this possibly a one-time anonymous identifier for Bob)

   <samlp:Response id="NTT3F633E3F712BAC4B0804714431D46D7B"
        inresponseto="NTT7630E00861279F0ADC63E241D0926D0B" version="2.0" 
        issueinstant="...">
      <saml:Issuer 
        format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://idpb.com
      </saml:Sssuer>
      <samlp:Status>
        <samlp:Statuscode value="urn:oasis:names:tc:SAML:2.0:status:Success">
      </samlp:Statuscode>
      <saml:Assertion version="2.0" issueinstant="..." id="NTT02068C15DFB">
        <saml:Issuer
           format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
          https://idpb.com
        </saml:Issuer>
        <saml:Subject>
          <saml:NameID namequalifier="https://idpb.com"    
            format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
            e0b735bf9d1f3959241d3584733d704c
          </saml:NameID>
        </saml:Subject>
        <saml:AuthnStatement authninstant="..." sessionindex="...">
          <saml:AuthnContext>AuthnContext goes here</saml:AuthnContext>
        </saml:AuthnStatement>
      </saml:Assertion>
    </samlp:Response>

7. Knowing that it needs to 'talk' to PSa about Bob, SPa sends IDPb an <sa:TokenMap> message, providing the previous name identifier for Bob and specifying PSa as the target namespace.

    <sa:TokenMap>
      <saml:NameID namequalifier="https://idpb.com" 
          format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
        e0b735bf9d1f3959241d3584733d704c
      </saml:NameID>
      <TokenPolicy spnamequalifier="https://psa.com">
      </TokenPolicy>
    </TokenMap>
 

8. IDPb returns an appropriately targetted(and likely encrypted) identifier for Bob that PSa will recognize.

    <sa:TokenResponse>
      <sec:Token>
        <saml:Assertion>
         identity token for Bob in PS's namespace
        </saml:Assertion>
      </sec:Token>
    </sa:TokenResponse>

9. As Alice has previously defined her access control rules in terms of a group maintained at PSa, SPa knows how to invoke PSa. SPa sends a query to PSa questioning Bob's membership in the group in question (the object for which is identified by the TargetID element), using the token just obtained from Bob's IDP to identity him.

    <ps:TestMembershipRequest>
      <ps:TargetID>https://ps.com/nmerflas</ps:TargetID>
      <sec:Token>
        <saml:Assertion>
         identity token for Bob in PS's namespace
        </saml:Assertion>
      </sec:Token>
    </ps:TestMembershipTequest>

10. PSa extracts the identity token, decrypts the encrypted identifier in the identity token, looks up the group in question, and finds that Bob is indeed a member (Alice having previously placed him there).

11. Consequently, PSa returns 'true' to SPa's original query.

    <ps:TestMembershipResponse>
      <Status code="OK">
       <ps:TestResult>true</ps:TestResult>
      </Status>
    </ps:TestMembershipResponse>

12. Confident that Bob is a member of the group against which Alice defined privileges, SPa grants Bob access to the resource in question.

Of course, all Bob would see of the above would be appropriate access to Alice's resources, everything happening behind the scenes.

Alternatively, when Alice first defined her access rule in terms of the 'Work Friend's group, the SPa could have then gone out and obtained individual identity tokens for all members of the group (from their respective IDPs). If and when somebody showed up trying to access a resource, SPa would check the identifier they presented against those in teh approved list and grant access accordingly. The issue with this model is dealing with changing group membership.