|From||Jonathan Sergent <sergent@Sun.COM>|
|Date||Fri, 24 Oct 2003 11:47:24 -0700|
Hi, sorry I didn't get a chance to reply until now.
On Thursday, Oct 23, 2003, at 16:00 US/Pacific, Stuart Jensen wrote:
The Discovery specification defines a ResourceID element that the Discovery, Personal Profile, and Employee Profile Services use. I have some questions about the format of the ResourceID.
From what I understand, the following is true:
The format of the ResourceID is specific to the implementation of the service.
The web service “registers” ServiceTypes and ResourceIDs with the Discovery Service.
A “client” will never have to create a ResourceID, it gets them from the Discovery Service. (as per the Discovery spec)
This is correct.
So, now some questions...
1) Does the Personal Profile Service have to register a unique ResourceID for every user record in its database? What if there are 500M users?
In the Personal Profile service, it appears that a “record” is a given user’s personal profile. When a <query> is made to the personal profile service, the only way the service will know which user record to access is by using the ResourceID.
It does, but it does not have to calculate random identifiers. It is allowed for you to make the ResourceID be calculated from the NameIdentifier you have for the user or any other key you need. The ResourceID does not need to be an opaque identifier because we have the EncryptedResourceID mechanism. I think Conor said this too.
The result of this is that you can turn it into a provisioning problem. In particular, if you have one entity hosting both Discovery and Profile and IDP, you don't need to send messages back and forth to populate the discovery entry; you can just use fixed calculated ResourceIDs for the user's resources at Discovery and Profile based on the user's identity at the IDP, for example if you are using a directory and my username is sergent you could say that the ResourceID for my discovery service is always http://myproviderid.com/discovery-resources/sergent. (You could use something like a distinguished name or entry ID number or something if you wanted too, of course.) You could then make the discovery service dynamically generate this result rather than actually create a copy of the data and store it for each user.
However, you should be prepared for situations where the discovery service is being used to register a profile that is hosted elsewhere rather than one that is administratively related to the discovery service. In this situation you are forced to deal with the fact that you have to register them all individually, the same way you would have to store ID-FF federation information for each user individually.
2) Given an SP that wants to access the Personal Profile Service, that SP makes a discovery lookup call to a Discovery Service. In that lookup XML there is a ResourceID element. This SP probably only has a username or pseudonym for the current user. How does the SP tell the Discovery Service which user it wants to locate the Personal Profile service for? There must be some mapping from username/pseudonym to ResourceID? The specs claim that a client will never have to create a ResourceID, so the ResourceID sent in the Discovery Service lookup must be different from the ResourceID returned in the ResourceOffering.... right?
Yes, the ResourceID you send in the DS lookup is for the DS resource itself.
The way you can get this is when you do ID-FF authentication of the user. Notice the SAML attribute defined in the discovery service specification. The attribute can be present in an attribute statement returned by the Liberty IDP when you authenticate the user (or by a SAML authority, for that matter). We usually call this bootstrapping, but I don't think that term appears in the spec.
So your ID-FF IDP ought to start returning this attribute statement with a pointer to the DS resource for the users it identifies. (Note that we have not specified how the IDP finds this information out. Our intention is that the typical IDP and DS instance are one and the same. However, we do not forbid them from being separate, but you would need to define some interface between them to enable this, and we have not tried to standardize this, because we don't think it's a very useful thing to do.)
I think I am missing some fundamental link..... and I would appreciate anyone's help to clarify.
The bootstrapping process is not very well explained. We are going to try to fix this with some better examples before we publish the spec.
I hope this helps clarify things.
— Jonathan Sergent / sergent@Sun.COM / (650) 352-6495
If you would like to unsubscribe from this list, please click on the URL below: https://www.projectliberty.org/member/unsubscribe/
The Liberty Alliance liberty-dev mail list archive can be viewed at the following URL:
Partial thread listing:
|Re: [liberty-dev] ResourceID Question, (continued)|
|Jonathan Sergent (10/24/2003)|
|John Kemp (10/24/2003)|
|Re: [[liberty-dev] Liberty Alliance Question], (IGOR IVANOV)|
|[liberty-dev] Liberty Alliance Question
|Conor P. Cahill (09/02/2003)|