monitoring and non-person IDs

Peter Schober peter.schober at univie.ac.at
Thu Jun 18 17:39:45 EDT 2015


* Jerry Shipman <jes59 at cornell.edu> [2015-06-18 14:54]:
> The campus group responsible for the application monitors its health
> with an automated process. The monitoring process uses a non-person
> ID (serviceid, holdingid, etc) to log in to the application and
> validate that the application is working. (I don't know the details,
> but for the sake of argument say that it logs in and presses some
> buttons, then parses the output, to verify that the application is
> functioning. Or something like that.) 
> 
> It seems like there may be policy or trust reasons why we would not
> want to do that same kind of authentication with a federated
> identity. i.e., if we set that same monitoring up to work with
> shibboleth, it would be possible for that non-person ID to wind up
> on another inCommon SP because our IdP is part of the
> federation. (It shouldn't happen, but it would be possible.)

You could avoid any dager of that by making sure that no attributes at
all are released for this specific identity, except for/to this one SP.
-peter


More information about the users mailing list