<div dir="ltr"><br> cacti.log contains:<br><b>WARNING: Invalid Response(s), Errors[3] Device[localhost] Graphs[localhost - Shibboleth IDP stats, localhost - Shibboleth IDP stats] Graphs[localhost - Shibboleth IDP stats, localhost - Shibboleth IDP stats] Graphs[localhost - Shibboleth IDP stats, localhost - Shibboleth IDP stats] DS[8,</b><br>while using the shibboleth-idp-stats template.<br>runidpstats.sh contains <b>/usr/bin/tac /opt/shibboleth-idp/logs/idp-audit.log | awk -f /usr/local/bin/parselog.awk |/usr/local/bin/loganalysis.py -t -</b><br>that results : rp:0 l:0 u:0<br><b> cat /opt/shibboleth-idp/logs/idp-audit.log |/usr/local/bin/loganalysis.py -t -</b><br>that results : rp:1 l:2 u:1<br><b> cat /opt/shibboleth-idp/logs/idp-audit.log |/usr/local/bin/loganalysis.py -cul -</b><br>1 unique relying party<br>1 unique userid<br>2 logins<br>I am using cacti 1.1.28 Please inform if any changes needed in default template.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 21, 2017 at 8:39 PM, <span dir="ltr"><<a href="mailto:users-request@shibboleth.net" target="_blank">users-request@shibboleth.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send users mailing list submissions to<br>
<a href="mailto:users@shibboleth.net">users@shibboleth.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://shibboleth.net/mailman/listinfo/users" rel="noreferrer" target="_blank">http://shibboleth.net/mailman/<wbr>listinfo/users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:users-request@shibboleth.net">users-request@shibboleth.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:users-owner@shibboleth.net">users-owner@shibboleth.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. RE: Support for signing key on hardware security modules<br>
(Cantor, Scott)<br>
2. RE: idp 3.0 MFA/DUO questions. (Cantor, Scott)<br>
3. Re: Configuration of Log Analysis Tool with Shibboleth Idp<br>
(Peter Schober)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Thu, 21 Dec 2017 14:24:40 +0000<br>
From: "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>><br>
To: Shib Users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>><br>
Subject: RE: Support for signing key on hardware security modules<br>
Message-ID:<br>
<<a href="mailto:9846A6064BD102419D06814DD0D78DE149EF3CA6@CIO-TNC-D2MBX02.osuad.osu.edu">9846A6064BD102419D06814DD0D78<wbr>DE149EF3CA6@CIO-TNC-D2MBX02.<wbr>osuad.osu.edu</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
> > I just don't have a great way to recognize the two groups.<br>
><br>
> You could force a migration to a new key and a new set of endpoints.<br>
> You already know how to do this but for the record, it goes something<br>
> like this:<br>
<br>
I know how to recognize them in general after the fact but identifying them automatically and without extra effort on my part is what I was referring to.<br>
<br>
My problem is that I've not really documented the non-adhoc integrations to this pont so I'm left with a long history of different cases between InCommon, not InCommon, and InCommon but ignoring the metadata. It's that last group I need to identify, but generally speaking I can tell from the metadata once I look. If it's Shibboleth or SSP, they probably are ok and if not, almost certainly not.<br>
<br>
-- Scott<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Thu, 21 Dec 2017 14:57:39 +0000<br>
From: "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>><br>
To: Shib Users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>><br>
Subject: RE: idp 3.0 MFA/DUO questions.<br>
Message-ID:<br>
<<a href="mailto:9846A6064BD102419D06814DD0D78DE149EF3D6C@CIO-TNC-D2MBX02.osuad.osu.edu">9846A6064BD102419D06814DD0D78<wbr>DE149EF3D6C@CIO-TNC-D2MBX02.<wbr>osuad.osu.edu</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
> At the moment I get a second factor (DUO) prompt for everything. I think<br>
> that's due to how I have the shibboleth.authn.MFA.<wbr>TransitionMap<br>
> configured<br>
<br>
You are explicitly telling it to do that. There's no "think" involved.<br>
<br>
> Eventually we will have about 10 to 15 SP's some will need MFA and some<br>
> won't. Some will be CAS protocol and some won't (not sure that matters).<br>
<br>
It matters in that you can't tell the CAS SPs to request what they want.<br>
<br>
> Questions:<br>
><br>
> 1. Where/how to define the logic of what apps/SP's need a second factor<br>
> and which ones don't?<br>
<br>
That depends on your end game. If you want a permanent "some do, some don't" environment, then have as many SAML SPs as possible do it on their own, ask for that they want and enforce it. Use the "isAcceptable()" method on the MultiFactorAuthenticationConte<wbr>xt object in the tree to test whether to bother adding Duo, which is in the example provided with the software.<br>
<br>
For the SPs that can't request it, or are using CAS, set the defaultAuthenticationMethods property to inject a requirement on their profile configuration bean(s) in a relying party override and block them from requesting something different. That's outlined in the documentation on that property, which is the second hit from a wiki search, ProfileConfiguration-<wbr>Authentication.<br>
<br>
If your end game is "eventually on for everything", I would just move there as quickly as possible by picking a couple of big apps that will cover your population, force those on with a relying party override, and once everybody's ready, just flip the switch. If you must take years with it, I'd still focus on turning them on at the IdP end.<br>
<br>
Either way the MFA logic is trivial: do Password, if mfaCtx.isAcceptable() then done, else do Duo.<br>
<br>
> 2. Eventually we will want to use some type of opt-in for apps that don't<br>
> require MFA, we are hoping to be able to do that based on and attruibute we<br>
> set in ldap is that possible? ( I think it is )<br>
<br>
I wouldn't if your end game is all on, it's just wasted time, but that's what the example that ships with the software does, but you want to do opt-in for everything or you're going to have ordering issues that will make it difficult to get the results you're expecting because the logic only runs when the system doesn't bypass it for SSO.<br>
<br>
-- Scott<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Thu, 21 Dec 2017 16:09:26 +0100<br>
From: Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>><br>
To: <a href="mailto:users@shibboleth.net">users@shibboleth.net</a><br>
Subject: Re: Configuration of Log Analysis Tool with Shibboleth Idp<br>
Message-ID: <<a href="mailto:20171221150926.z26bupc7yapzbqnf@aco.net">20171221150926.<wbr>z26bupc7yapzbqnf@aco.net</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
Quick update on the recently revived audit log parsing script:<br>
<br>
* Peter Schober <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> [2017-12-20 14:11]:<br>
> Note that there's now again a public home for loganalysis.py,<br>
> <a href="https://github.com/peter-/shib-idp-auditlog" rel="noreferrer" target="_blank">https://github.com/peter-/<wbr>shib-idp-auditlog</a> The code is still the<br>
> old one and I'm not actively working on this, but if anyone has<br>
> useful things to add by all means send a pull request. I might also<br>
> try to hunt down changed versions and add those changes to this<br>
> repo.<br>
<br>
I've meanwhile added leifj's XML output contribution (from 2011, which<br>
never made into Internet2's SVN), Jehan Procaccia's output mode for<br>
easier RRD processing (from 2012; independently published and never<br>
submitted for inclusion), and just now added a JSON output method.<br>
<br>
Note that this now requires (and has been tested with) Python 2.6 or<br>
2.7, or Jython 2.7.<br>
<br>
I've removed the option `-p` (events per relying party) since `-n` did<br>
the same thing plus numerical sorting of the output, and the speed<br>
differences are negligible, IMO.<br>
<br>
The old code still running on Python 2.3 has been tagged as v1.0, for<br>
those seriously stuck on ancient systems.<br>
<br>
-peter<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/<wbr>confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
<br>
------------------------------<br>
<br>
End of users Digest, Vol 78, Issue 66<br>
******************************<wbr>*******<br>
</font></span></blockquote></div><br></div>