Shibboleth Developers

["Alistair Young" <>]

> The discovery service is a web service
absolutely.

> Maybe you mean you want it to be a SOAP service?
;) machine to machine, yes. If it was an SDS it would be machine to
machine, SOAP, WS-Security + SAML token and all that for AAA, as a SOA
brick would require. Just about any language is capable of cobbling
together an XML based packet these days. Even Python I believe, although I
haven't seen a Python SP (yet).

When I referred to "web service" (and all that that can mean) I was
contrasting with Scott's view that the SP should do all the discovery leg
work, which isn't SOA compatible. I think that's what he was saying.

Alistair


-- 
mov eax,1
mov ebx,0
int 80h

> The discovery service is a web service.  It is a service accessible via
> HTTP that takes in input and provides you output based on it's business
> processes.  This is perfectly reasonable as an SOA component.
>
> Maybe you mean you want it to be a SOAP service?
>
> Alistair Young wrote:
>>> And I think people should just stop trying to offload discovery and do
>>> it
>>> in
>>> the application where the decision can be made with the most
>>> information.
>> is that not against the SOA movement these days? Having a big blob of an
>> SP, with duplicated functionality in each one, all needing updated to
>> keep
>> up with profile changes?
>>
>> Yes the SP will have most of the information but the DS will have some
>> too
>> and the decision will be based on rules that could change all the time.
>>
>> The discovery service as a service that, given enough information, could
>> make a decision on a likely source of identity. e.g. the simplest piece
>> of
>> information could be the IP address that the original request came from.
>> That would have to be metadata lookup. I wouldn't want an SP to have
>> that
>> sort of metadata, to be updated across all SPs. Rather have it in the
>> discovery "service". A "web service". An authenticated, authorised web
>> service. A brick in the eFramework. It wouldn't need a ui if the SP does
>> this next:
>>
>> If nothing came back from the service then the SP just spews out it's
>> metadata for IdPs and says "ok, find it yourself".
>>
>> I think the "find it yourself" bit is what you say SPs should do
>> themselves but cutting down on the options based on info a user can
>> produce at the time (IP, perhaps resource uri etc.)
>>
>> A semantic discovery service (SDS) would be an interesting creature.
>> Client from 10.192.3.2 wants to access /medicalimages/gore.jpg. hmmm
>> says
>> SDS, I know that that IP block has several IdPs and that one of them is
>> in
>> the Faculty of Cutting Things Up. Ontological references equate cutting
>> things up with medical images. "That's your best bet" it says to the SP.
>> SP says, is this your IdP? If yes, SP can communicate back to SDS saying
>> "well done" and SDS learns...
>>
>> Alistair
>>
>>
>
> --
> Chad La Joie             2052-C Harris Bldg
> OIS-Middleware           202.687.0124
>