Information about current federation statistics:
| Federation | Currently Collect Stats? | Published? | Format? | Possible to push to a central service? | Willing to push to a central service? | WAYF Stats |
|---|---|---|---|---|---|---|
| SIR(2) | Basic - "IdP x SP x accesses" matrix, calculated daily. | Only privately to IdP admins. | Data is stored in a MySQL database, and can be exported to CSV/XLS/PDF from the web interface, filtering/resuming by date ranges. | When SIR2 is up and running. | When SIR2 is up and running. | - |
| RENATER | No | - | - | - | No | |
| HAKA | Yes | Yes, but need to be able to login | We're using log analysis tool contributed by shibboleth ( Our instructions for IdP Maintainers -> https://confluence.csc.fi/display/HAKA/Usage+statistics+from+IdP ). This data provided by log analysis tool is saved by IdP Maintainers to location where from we're able to fetch em (and save to our database). We also have statistics page where this data can be seen in visual form. There are three different point of views, total, by IdP and by SP. * All.Logins - Shows total logins to SP's and IdP's, Most used ones are easily spotted here. * logins.from.IdP - you can select IdP and see logins to services from that IdP. * logins.from.SP - If you select an SP you can see IdP's where from logins are performed. | Technically yes | Would need discussion with Steering Group. | - |
| UK federation | No | - | - | - | - | Yes, but numbers very non-representative as SPs encouraged not to use. |
| GRnet | For GRnet IdPs yes, but not for general IdPs | No | We use Raptor and we have raw data in a database ( MySQL ) but currently N/A on a federation level | Only if it was RAPTOR based | Would need internal discussion but possible. | we are in the process of making extended modifications to our WAYF service and statistics collection is one of the considerations for enhancements. |
| AAI@EduHr | Yes | http://f-ticks.aaiedu.hr/statistike/ | f-ticks, also saved in a database | Would need to agree a format. | yes | - |
| FEIDE | We do not collect anything identifying the user in our statistics data. Thus we cannot say anything about unique users. We do however collect login events. | It is available to IdPs and SPs connected directly to Feide, through our customer portal. | The original data is in the form of structured log events, encoded in JSON: { "spEntityID":"urn:mace:feide.no:services:no.uninett.feidekundeportal", "idpEntityID":"https:\/\/idp.feide.no", "feideSchoolList": ["NO968100211"], "org":"uninett.no", "previousSSO":false, "op":"login", "time":1441008935.3942, "_id":"0000000055e40d276fb78e14607498c76d7d900486a024ea" } It is stored in various forms. The current authorative datastore is a MongoDB database. We also push it into ElasticSearch for access through Kibana. From the events we also produce some aggregated statistics counting the various events over different timescales. (In addition to login events, we collect a lot of other structured log data, e.g. total time through the login process, from start to end, login failures, logout events, etc.) | Possibly | Would need internal discssion | - |
| AAF | We have a project underway to improve this situation by collecting logs for all IdPs to a central point which will give us much greater insight into the activities of the federation. | They are available from within the Federation Registry. Restrictions apply to access to detailed reports. We also publish summary information in our annual reports. | Currently stored in a MySQL database. Not sure how / where will be held in the future. | Anything is possible  | Further internal discussions would be required and an understanding of the benefits. | - |
| Tuakiri | As AAF | As AAF | As AAF | As AAF | As AAF | |
| SWAMID | Yes | flog.sunet.se | f-ticks | you're talking aggregate information? do we have a simple format for that sort of thing? maybe we need a federation MIB | In principle. See Linus Nordberg (CT, Tor etc) about how to architect a reasonably safe depository for usage information that could be use to support things like "long-term-key logout", eg for the purpose of doing threat mitigation for hacked accounts. | Do not keep on purpose. |
SurfConext | Yes, we collect logins, unique users per SP, IdP and totals. We currently only publicly show live stats for logins per min/hour/day/month/year | https://stats.surfconext.nl/live/index.html Today showing a nice new record number of logins as the new academic year has started thins week in The Netherlands | Raw data in MysQL, aggregated data in MySQL as well | Assuming it is both periodic, script-able and high-level, yes | Assuming it is both periodic, script-able and high-level, yes | - |
| Aconet | no | - | - | - | - | Fyi, we currently are running 5 instances of "fallback" discovery services: 4 more or less supported ones (albeit experimental wrt their take-up within our community), and 1 widely deployed but deprecated one: https://wiki.univie.ac.at/display/federation/Discovery+Services Since we recommend to NOT use any of them (as per best practices in this area and from this very community, https://discovery.refeds.org/) we don't have added any tooling so far to systematically collect and process the data from those 5 discovery services. (Also for the DiscoJuice-based ones we don't have any logs at all, AFAIK.) Even in the logs we do have obviously we have no uniquely identifying attribute of the subject operating the HTTP User Agent, so any questions about "[unique] users" could only be answered in terms of IPv6 and IPv4 addresses (which could be proxies, etc.). So all in all not worth the effort, IMHO. |
| WAYF | Yes | simple MySQL db | Possibly | Simple stats - yes | - | |
| Edugate | Yes | Service providers can collect their stats from our registry, so can Identity providers, the aggregate data is displayed internally only | The data is held in a Raptor database, graphed with rrdtool. | Yes | Yes, but limited to aggregate stats, our SP’s (and maybe IdPs) may view their entity stats as commercially sensitive. | - |