Shibboleth Developers

["wz qiang" <>]

hi Tom,

Could you explain a little more about the Grid Use Case?

my question follows your sentences.

 

Thanks you

Weizhong

 

On 10/31/07, Tom Scavo <> wrote:

This use case distills the common requirements of various grid
projects I've worked on, and so it might be called the "Grid Use
Case":

1. The IdP asserts an SSO assertion with the following characteristics:
* The assertion is unencrypted
* There is a digital signature on the <Assertion> element
* The <AuthnContext> element distinguishes between two levels of assurance
* The IdP asserts a persistent, non-reassignable identifier (encrypted)
* The assertion may contain non-identity attributes such as ePSA (unencrypted)

 

So the IdP will do two things: authenticate the user by using the user's identity certificate, and acquire attribute for the user?

2. The SP decrypts the identifier and maps it to a persistent, local
identifier (account linking).

 

What is the scenario if local identifier mapping/linking? some gridmap-like thing?

For the SP or the application, do they still authenticate the user once more by using the user's identity certificate, or they just rely on the assertion from the IdP (identity asserted by IdP)?

 

what is the non-assignable identifier? is it still the DN from the user's certificate? or some other things?

And it will be encrypted by what?

3. The SP resolves local attributes and issues a local attribute
assertion with bound SSO assertion (in <Advice>).

 

What is the scenario about local attribute? do you mean some role/group information which will be assigned to the user?

4. SP exposes the local attribute assertion to the application.

Questions:

* Can the Shib IdP 2.0 be made to issue such an assertion?
* Will the Shib SP 2.0 do account linking?
* Will the Shib SP 2.0 do local attribute resolution?
* If the answer to the previous question is no, will the Shib SP 2.0
expose the raw SSO assertion?

Thanks,
Tom