monitoring and non-person IDs

[Jerry Shipman]

Hello,
Thank you for the feedback.

I am sorry, I think that I probably rambled on and it was not clear. I had intended to ask a policy/practice question rather than a technical/implementation question. 
I think something along the lines of: 
  "what steps should we take in order to be a good citizen of the federation, while monitoring these applications?"

>From the responses I gather that lots of people are doing this, so there are no insurmountable philosophical problems.

I thought of two specific things that we might be able to do:
 - One is what Peter mentioned (release no attributes for that user to any SP except the one it's monitoring). (I didn't try that out yet but it seems like it would be possible, albeit at the cost of bulking out the IdP configuration.)
 - The other was that I could make sure that we never assert any eduPersonAffiliations for monitoring users. 

Is there a better option that I didn't think of?
Does anyone know of a recommendation or requirement or preference from the federation about what steps should be taken?

Thanks again,
Jerry





On Jun 18, 2015, at 5:40 PM, <users-request at shibboleth.net> wrote:

> Date: Thu, 18 Jun 2015 23:39:45 +0200
> From: Peter Schober <peter.schober at univie.ac.at>
> To: users at shibboleth.net
> Subject: Re: monitoring and non-person IDs
> Message-ID: <20150618213945.GS2170 at aco.net>
> Content-Type: text/plain; charset=us-ascii
> 
> * 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
> 

On Jun 18, 2015, at 12:00 PM, users-request at shibboleth.net wrote:

> Date: Thu, 18 Jun 2015 09:13:57 -0400
> From: Tom Scavo <trscavo at gmail.com>
> To: Shib Users <users at shibboleth.net>
> Subject: Re: monitoring and non-person IDs
> Message-ID:
> 	<CAEtu=dPBO5x=Pme8DX0_k_bBQH6fEk7WVzZszvNisFdFXC-V6A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Thu, Jun 18, 2015 at 8:53 AM, Jerry Shipman <jes59 at cornell.edu> wrote:
>> 
>> Does anyone have recommendations on how to monitor a shibboleth-protected SP with a non-person ID in a reasonable way, given that our IdP is a member of the federation?
> 
> I don't know of an out-of-the-box solution (i.e., something you can
> just download and run) but you can completely automate SP testing with
> an IdP that has a test account set up for basic authentication. A
> script can log into the IdP and push a SAML assertion to the SP.
> That's what we did to find SPs that didn't support assertions signed
> using a SHA-2 digest algorithm. This wiki page (and its child pages)
> might be useful to you: https://spaces.internet2.edu/x/JAJkAg
> 
> Hope this helps,
> 
> Tom

> Date: Thu, 18 Jun 2015 14:02:50 +0000
> From: "Wessel, Keith" <kwessel at illinois.edu>
> To: Shib Users <users at shibboleth.net>
> Subject: RE: monitoring and non-person IDs
> Message-ID:
> 	<A1EB7EC659FA0F429A55865D5820006D2E2A8AF3 at CITESMBX1.ad.uillinois.edu>
> Content-Type: text/plain; charset="us-ascii"
> 
> I'll add that we're doing scripted monitoring of our IDP (previous thread from a few months back on this list) using Jim Fox's very excellent webisoget: http://staff.washington.edu/fox/webisoget/
> 
> Since putting this in place, many of our SP poerators have been joining efforts to use a similar approach to monitor Shib-protected resources on their SPs. I wrote a very simple Perl script that wraps around webisoget to use it as a Nagios probe.
> 
> Keith


On Jun 18, 2015, at 8:55 AM, users-request at shibboleth.net wrote:
> Date: Thu, 18 Jun 2015 12:53:54 +0000
> From: Jerry Shipman <jes59 at cornell.edu>
> To: "users at shibboleth.net" <users at shibboleth.net>
> Subject: monitoring and non-person IDs
> Message-ID: <EC12486C-B37C-455C-9518-F50B3C877D47 at cornell.edu>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hello,
> 
> (This might not be the right list for this question, but I thought that people on here would know what I mean and have suggestions. Apologies if I am doing that wrong.) 
> 
> We have a web application that is moving from on campus to being vendor-hosted in "the cloud", and as part of that move the authentication is changing from our internal system to shibboleth. The vendor is a member of incommon and the SP is registered.
> 
> 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.)
> 
> Does anyone have recommendations on how to monitor a shibboleth-protected SP with a non-person ID in a reasonable way, given that our IdP is a member of the federation?
> 
> For example, 
> - maybe it is acceptable if we don't assert any eduPersonAffiliations for that non-person ID?
> - I might be able to do something in the attribute-filter.xml to restrict that specific user to only being able to log in to that specific SP (i.e. by not releasing any attributes to any other SP, so they just get an empty assertion -- sort of ugly). I haven't looked into that option enough yet to be able to tell whether it is feasible. 
> 
> What have other people done? Is there a standard solution? Or does anyone have any suggestions?
> 
> Thanks a lot for the help,
> Jerry Shipman
> 
>