This option was added throughout the application. The setting will be saved to the event store, but is also projected to the institution configuration projection. This way the setting can be retrieved via the Middelware management API. At this location the option is also evaluated to store it for both new and existing institutions. For institutions without the configuration option, the default 'false' is configured.

I later also added the actual SelfVet command, used to indicate a self vet option was used. This resulted in quite a lot of additional code changes. Maybe better to review them on a per-commit basis to keep things somewhat manageable.

Be advised! a migration was added to project the new setting. Be sure to run your Doctrine migrations command

This PR will not pass on travis on account of the security tests failing. They are patched up in #321. I do not see any security advisories on that branch. So this should be green too.

See: https://www.pivotaltracker.com/story/show/176714989 See: https://www.pivotaltracker.com/story/show/176715329

Allow bootstrapping of an Identity with an SMS token. Three verification states can be achieved: Unverified, Verified and Vetted.

Example usage: app/console middleware:bootstrap:identity-with-sms my:fancy:name-id institution-a.example.com "Jesse James" "[email protected]" en_GB "+31 (0) 612345678" vetted

Some open ends:

• Solve the authority id issue (which RA is vetting the token?) Either save the actor id on the event or in the metadata. For now does not have to end up in the audit log, but should be saved.
• ~Review the overall structure of the command, and look into making the code more maintainable, readable and robust~
• Discuss the separation of the identity creation logic to another command

PM @phavekes expressed his preference to keep the logic bundled in the command. I did however move the creation logic to an abstract command. That way other similar bootstrap events can borrow that logic.

• ~Be 'email verification required' aware~

https://www.pivotaltracker.com/story/show/172429585

This reverts commit a1543deca6a1f989b12eca2c119644b3fa951a6a, reversing changes made to 4b0c8a62ef1182754d887529d2f98ca4f20ae291.

In the Identity aggregate, it is not known whether a certain identity is an SRAA or not. If he is an SRAA, the registrationAuthority property is set to null -- contrary to what one might assume. That is why these checks currently do not work.

In the future, we need to find another way to determine in the Identity aggregate whether the one doing the vetting is a registration authority and whether he is an SRAA. See: https://www.pivotaltracker.com/story/show/135335407

Reverting this means that, in theory, any Identity can vet a second factor regardless of whether they are within the same institution. However, these checks are already done by the front-ends: RA and SS.

This reverts work done in PR #160.

The implicit __toString call is no longer allowed, and a critical error is raised by Twig. The solution is to add the __toString calls to the list of allowed sandbox methods.

This change fixes the problem where sending the verification mail message would trigger an error.

• Removes concept of vetting locations in favor of separate concepts (RAs/RA locations)
• Removes concept of institutions with RA locations in favor of institution configuration options
• Fixes flaws in saving institution configuration options and handling commands

This depends on the service introduced in #146

GET /institution-configuration-options/dev.organisation.example

{
  "use_ra_locations": false,
  "show_raa_contact_information": true
}

The RA-Candidates were filtered on RA institution but that should have been on institution. Because we only want to use identities from the institutions we are currently RA for.

https://www.pivotaltracker.com/story/show/171703175

After the fix to be able to login with the highest ra(a) level the original static method was removed, but this shouldn't be removed. Restored the original method to allow construction of ra-listings.

This PR will add the changes to the Aggregateroot to allow FGA in middleware. There are however a few changes that still needs to be adressed before this PR could be merged and those changes are:

• [x] Test the accredit identity unhappy flow
• [ ] Add behat coverage for select_raa
• [ ] Events have been documented (in class documentation and/or on wiki)

Also the commits need to be rebased before merge to have atomic commits and better commit logs.

See: https://www.pivotaltracker.com/story/show/160283517

Initial error report:

[root@test-app Stepup-Middleware-2.0.0-20160808152839Z-b38acd98a77c89bffa2649d956f92709954aa036]# php app/console cache:clear --env=prod --no-debug
Clearing the cache for the prod environment with debug false
PHP Fatal error:  Class 'PHPUnit_Framework_TestCase' not found in /opt/stepup/Stepup-Middleware-2.0.0-20160808152839Z-b38acd98a77c89bffa2649d956f92709954aa036/src/Surfnet/StepupMiddleware/ApiBundle/Tests/Configuration/Entity/ConfiguredInstitutionTest.php on line 26
[Symfony\Component\Debug\Exception\ClassNotFoundException] Attempted to load class "PHPUnit_Framework_TestCase" from the global namespace.  Did you forget a "use" statement?

What seems to happen is that the cache cannot be cleared due to Test classes being loaded during the cache:clear command.

In order to reproduce this locally, run:

SYMFONY_ENV=prod composer install -o --no-dev

This should remove any dev dependencies and then attempt to clear the cache as if Symfony was running in prod mode, therefor causing a similar or the same error. This is reproducible with a command as reported originally:

SYMFONY_ENV=prod app/console c:c --env=prod --no-debug

For me this resulted in:

Clearing the cache for the prod environment with debug false
PHP Fatal error:  Class 'PHPUnit_Framework_TestCase' not found in /opt/workspace/SURFnet/Stepup-Middleware/src/Surfnet/StepupMiddleware/ApiBundle/Tests/Configuration/Entity/RaLocationTest.php on line 28
PHP Stack trace:
PHP   1. {main}() /opt/workspace/SURFnet/Stepup-Middleware/app/console:0
PHP   2. Symfony\Component\Console\Application->run() /opt/workspace/SURFnet/Stepup-Middleware/app/console:25
PHP   3. Symfony\Bundle\FrameworkBundle\Console\Application->doRun() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:120
PHP   4. Symfony\Component\Console\Application->doRun() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:90
PHP   5. Symfony\Component\Console\Application->doRunCommand() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:189
PHP   6. Symfony\Component\Console\Command\Command->run() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:852
PHP   7. Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand->execute() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:256
PHP   8. Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand->warmup() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Command/CacheClearCommand.php:92
PHP   9. Symfony\Component\HttpKernel\Kernel->boot() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Command/CacheClearCommand.php:128
PHP  10. Symfony\Component\HttpKernel\Kernel->initializeContainer() /opt/workspace/SURFnet/Stepup-Middleware/app/bootstrap.php.cache:2447
PHP  11. Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerAggregate->warmUp() /opt/workspace/SURFnet/Stepup-Middleware/app/bootstrap.php.cache:2677
PHP  12. Symfony\Bridge\Doctrine\CacheWarmer\ProxyCacheWarmer->warmUp() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/CacheWarmer/CacheWarmerAggregate.php:48
PHP  13. Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() /opt/workspace/SURFnet/Stepup-Middleware/vendor/symfony/symfony/src/Symfony/Bridge/Doctrine/CacheWarmer/ProxyCacheWarmer.php:69
PHP  14. Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain->getAllClassNames() /opt/workspace/SURFnet/Stepup-Middleware/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:114
PHP  15. Doctrine\Common\Persistence\Mapping\Driver\AnnotationDriver->getAllClassNames() /opt/workspace/SURFnet/Stepup-Middleware/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php:128
PHP  16. require_once() /opt/workspace/SURFnet/Stepup-Middleware/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/AnnotationDriver.php:236


  [Symfony\Component\Debug\Exception\ClassNotFoundException]                       
  Attempted to load class "PHPUnit_Framework_TestCase" from the global namespace.  
  Did you forget a "use" statement?                                                


cache:clear [--no-warmup] [--no-optional-warmers]

This indicated that Doctrine was the culprit when attempting to generate the cache files for all entities within a specific mapping. This would trigger loading of test files, which apparently breaks things. Being more specific in the mapping circumvents this.

Create identity read model resource, not limited by institution for now. This, so the read model API can be built in the Middleware API client package.

When vetting_type is not present in the event data, the default vetting type is used (VettingType::UNKNOWN).

See: https://www.pivotaltracker.com/story/show/184060757

When an institution is configured to use RAA's from another institution, but the useRa is not set for that same institution. And a RAA user is made RAA for that institution. He/She is not allowed to perform RA actions (vet second factor and revocation of a token).

This is because in the authorisation service we 'downgrade' the Vet and Revoke actions to require the use ra role.

The succesive buildInstitutionsAuthorizationContext then searches for the institutions that have that useRa role applied. None are found, an authorization exception is raised.

To fix this. Either add both the useRa and useRaa actions to the authz context. Or make the parent method more user context aware. Where we would have to check that if the useRaa role is applied for either one of the Vet or Revoke events, we should set the useRaa role instead of the hard coded useRa.

See: https://www.pivotaltracker.com/story/show/180081100