You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

This page collects proposals for future Incubator activities. Anyone may add a new idea by adding a new row to the table below.

Ideas don't need to be fully formed but the more scope we can get the easier it will be to assess whether the idea should be taken forward.  

Anything in the Trust and Identity space is of interest, from improvements to current services to brand new ideas and technologies.

If you like an existing idea you can just add a +1 for endorsement. The more supporters a proposal gets the more likely it is to be implemented.

Example from a previous cycle


TitleProposerDescriptionSupporter (+1)

Self service - Signing in activity

Janusz Ulanowski
(HEAnet CLG)

Service which could allow an user to check signing in activity on IdP service. That would allow an user to check the recent activity on his account in regards of authentication. Users could see the list if authentications containing datetime, ip and relying party etc. That would help them to spot suspicious activity.

After discussion in the Incubator board, the proposal for the Incubator is inspired by the above proposal, but with a slight difference:

Setting up a service as proposed originally is rather challenging as that service would have to learn about a lot of personal data. However, 'account activity', deployed as part of an IdP extension would actually improve privacy and GDPR compliance of e.g. SimpleSamlPHP and Shibboleth.
Proposal is to create such extensions for SSP and Shibboleth in close collaboration with the relevant community

Both SimpleSamlPHP and Shibboleth as well as also support the OIDC protocol. A 'profile page' should also allow an end user to manage and revoke OIDC access.

Janos Mohacsi: it would be advantageous to have a standardised log format  to all popular IdPs. Then these logs should be dumped to ELK or similar server. The log collection server should  provide a restricted access to the logs of a particular users.

Mihály Héder: I think an Audit Log self-service is an interesting functionality. Account activity is available in many commercial accounts, certainly the googles and the microsofts of the world. We should keep up - also not only the IdP Audit Log but the SP is relevant.

Proposals:

Proposal details:

TitleProposerDescriptionSupporter (+1)
Scalable testing for insecure SAML signature validation
Thijs Kinkhorst (SURF)

The SAML 2.0 protocol relies on XML signatures as the foundation of its security. A SAML assertion is signed with XMLDsig and the SP must properly validate this signature. If it does not, basically anyone in the world can trivially provide it with assertions thereby logging in as anyone, which also cannot be easily detected or even seen by the IdP. XMLDsig (and SAML) is notoriously complex and allows for many ways to create one or more signatures for any document. This makes that an implementation can easily fall victim to accepting not properly signed data - and even common implementations in our world like Shibboleth and SimpleSAMLphp have had issues here in the past. Besides these common products, which at least are periodically audited for such problems, a much larger risk is custom implementations that use different or even home grown libraries. Most of the times, the happy path is tested (does login work), but the unhappy path (do invalid assertions fail), not so much.

Given the paramount importance of signature validation, we should have a way to test whether SPs check signatures correctly. Although this can be done manually already, what's lacking is a scalable way that can test e.g. eduGAIN-like size of service providers (repeatedly) and for a large proportion of that set, determine if signatures are processed correctly. This requires to devise tests to fire off at these SPs and heuristics to determine automatically whether the tests passed or failed.

Some ideas of specific scenarios to test, all of which we've seen in real life to fail:

  • Signature not checked at all, modified message accepted
  • Modified message with signature rejected, but message without any signature accepted
  • Multiple signatures on the same message/signature wrapping attacks
  • Correctly signing a part of the message but unsigned part with attributes accepted.

Peter Brand (ACOnet)

Automation of
deployment and
configuration
of initial set of SPs
for new federations
Mario 
Reale
(GÉANT)

While supporting new federations in setting up their infrastructures, IdPs and SPs,  generally speaking, we still do not have much automation in place. All is done, still very manually, and takes much time. Talking specifically of the SPs, both for the installation and configuration of the services themselves, and the required operations to federate them, and make them fully functional SAML2 Service Providers, in order to be able to provide them in a federated (e.g.eduAGAIN) fashion.

It would be useful to enhance the level of support we provide to them with the aim of quickly being able to deploy an initial set of services, the ones which could de-facto start to attract users towards the newly deployed federation infrastructure and the federated IdPs. 

The idea here is to propose  a new cycle of T&I incubator task activities aimed at the following tasks:

  1. Identifying an initial set of 2-3 services we’d like to promote as SPs to the new identity federations. (e.g.: Wiki, Moodle, Joomla, eduMEET, Filesender, ..)
  2. Design a solution based on automation, possibly using containers, or automated deployment tools like Ansible, Puppet (which we should aim at making easy for early services deployers), for the services we’d like to deploy. Or any script with the corresponding clear, easy to use documentation which would do as much of the initial installation and configuration work as possible, leaving to a minimum the amount of residual manual interventions required. 
  3. Define a technical and strategic roadmaps to ensure sustainability of these deployment solutions: how will they be upgraded/ported to new versions, which task, or permanent activity in the GN project, or the community could endorse the future work to keep the developed solution working also in future.

    This proposal is about using a full Incubator cycle  to develop an initial solution, work on it, and add some work to design in a clear way how things can be made sustainable after the T&I cycle would be over. 

 


Davide Vaghetti (GARR)

  • No labels