users Digest, Vol 78, Issue 66

Sat Dec 23 08:25:55 EST 2017

cacti.log contains:
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,
while using the shibboleth-idp-stats template.
runidpstats.sh contains /usr/bin/tac
/opt/shibboleth-idp/logs/idp-audit.log | awk -f /usr/local/bin/parselog.awk
|/usr/local/bin/loganalysis.py -t -
that results : rp:0 l:0 u:0
 cat /opt/shibboleth-idp/logs/idp-audit.log
|/usr/local/bin/loganalysis.py -t -
that results : rp:1 l:2 u:1
 cat /opt/shibboleth-idp/logs/idp-audit.log
|/usr/local/bin/loganalysis.py -cul -
1 unique relying party
1 unique userid
2 logins
I am using cacti 1.1.28 Please inform if any changes needed in default
template.

On Thu, Dec 21, 2017 at 8:39 PM, <users-request at shibboleth.net> wrote:

> Send users mailing list submissions to
>         users at shibboleth.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://shibboleth.net/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
>         users-request at shibboleth.net
>
> You can reach the person managing the list at
>         users-owner at shibboleth.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>    1. RE: Support for signing key on hardware security modules
>       (Cantor, Scott)
>    2. RE: idp 3.0 MFA/DUO questions. (Cantor, Scott)
>    3. Re: Configuration of Log Analysis Tool with Shibboleth Idp
>       (Peter Schober)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Dec 2017 14:24:40 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: Shib Users <users at shibboleth.net>
> Subject: RE: Support for signing key on hardware security modules
> Message-ID:
>         <9846A6064BD102419D06814DD0D78DE149EF3CA6 at CIO-TNC-D2MBX02.
> osuad.osu.edu>
>
> Content-Type: text/plain; charset="us-ascii"
>
> > > I just don't have a great way to recognize the two groups.
> >
> > You could force a migration to a new key and a new set of endpoints.
> > You already know how to do this but for the record, it goes something
> > like this:
>
> 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.
>
> 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.
>
> -- Scott
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Dec 2017 14:57:39 +0000
> From: "Cantor, Scott" <cantor.2 at osu.edu>
> To: Shib Users <users at shibboleth.net>
> Subject: RE: idp 3.0 MFA/DUO questions.
> Message-ID:
>         <9846A6064BD102419D06814DD0D78DE149EF3D6C at CIO-TNC-D2MBX02.
> osuad.osu.edu>
>
> Content-Type: text/plain; charset="utf-8"
>
> > At the moment I get a second factor (DUO) prompt for everything.  I think
> > that's due to how I have the shibboleth.authn.MFA.TransitionMap
> > configured
>
> You are explicitly telling it to do that. There's no "think" involved.
>
> > Eventually we will have about 10 to 15 SP's  some will need MFA and some
> > won't. Some will be CAS protocol and some won't (not sure that matters).
>
> It matters in that you can't tell the CAS SPs to request what they want.
>
> > Questions:
> >
> > 1. Where/how to define the logic of what apps/SP's need a second factor
> > and which ones don't?
>
> 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 MultiFactorAuthenticationContext object in the tree to test
> whether to bother adding Duo, which is in the example provided with the
> software.
>
> 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-Authentication.
>
> 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.
>
> Either way the MFA logic is trivial: do Password, if mfaCtx.isAcceptable()
> then done, else do Duo.
>
> > 2. Eventually we will want to use some type of opt-in for apps that don't
> > require MFA, we are hoping to be able to do that based on and attruibute
> we
> > set in ldap is that possible? ( I think it is )
>
> 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.
>
> -- Scott
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Dec 2017 16:09:26 +0100
> From: Peter Schober <peter.schober at univie.ac.at>
> To: users at shibboleth.net
> Subject: Re: Configuration of Log Analysis Tool with Shibboleth Idp
> Message-ID: <20171221150926.z26bupc7yapzbqnf at aco.net>
> Content-Type: text/plain; charset=us-ascii
>
> Quick update on the recently revived audit log parsing script:
>
> * Peter Schober <peter.schober at univie.ac.at> [2017-12-20 14:11]:
> > Note that there's now again a public home for loganalysis.py,
> > https://github.com/peter-/shib-idp-auditlog The code is still the
> > old one and I'm not actively working on this, but if anyone has
> > useful things to add by all means send a pull request. I might also
> > try to hunt down changed versions and add those changes to this
> > repo.
>
> I've meanwhile added leifj's XML output contribution (from 2011, which
> never made into Internet2's SVN), Jehan Procaccia's output mode for
> easier RRD processing (from 2012; independently published and never
> submitted for inclusion), and just now added a JSON output method.
>
> Note that this now requires (and has been tested with) Python 2.6 or
> 2.7, or Jython 2.7.
>
> I've removed the option `-p` (events per relying party) since `-n` did
> the same thing plus numerical sorting of the output, and the speed
> differences are negligible, IMO.
>
> The old code still running on Python 2.3 has been tagged as v1.0, for
> those seriously stuck on ancient systems.
>
> -peter
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
> ------------------------------
>
> End of users Digest, Vol 78, Issue 66
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20171223/5cf520cd/attachment.html>