search

wayf-dk / corto

Automatically exported from code.google.com/p/corto
0 stars 0 forks source link

New extensible architecture for Corto #1

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
We want to use Corto in production for a product which does SAML2 proxying and 
more.
In order to use and extend Corto without our product some refactoring is 
required.

1. Use of a coding standard: Zend Framework Coding Standard.
2. Descriptive variable and function names.
3. An OO architecture where extensibility can be achieved via a 'modular' 
approach, Corto is broken up into several pieces:
- Base classes like Cort_ProxyServer and Corto_XmlToArray
- Proxy modules, that are injected into (or set on) and bound to (injected with 
a reference to) the ProxyServer.
See attached screenshots.

Use of this new architecture ensures that we can extend the server (so it can, 
for instance recognize our own URLs) and inject extended modules (where we can 
add, by simply adding a method, or modify services on the services 
class/module).

Requirements of this new architecture are:
- High performance (low I/O)
- High reliability
- Highly extensible
- Low abstraction level
- Compilable to single (PHP or Phar) file with specific configuration and 
metadata.

See attachment for an overview of the proposed architecture.

Original issue reported on code.google.com by relaxno...@gmail.com on 6 Aug 2010 at 3:07

Attachments:

GoogleCodeExporter commented 9 years ago 
Our specific requirements of Corto are as follows:
- Forward an AuthReq from a SP to a preselected IdP using the URL (multi-level 
URL)
- Generate metadata for a Corto hosted entity as a SP.
- Generate metadata for a Corto hosted entity as an IdP.
- Generate metadata for all known IdPs where the locations are multi-level URLS
  - ... and include a specified SP (as a Shibboleth SP I want to see myself in the metadata)
- Once an assertion of a successful authentication has been received, provision 
the user in a LDAP directory.
- Once an assertion of a successful authentication has been received, check if 
the user has consented to the use of these attributes and their values for the 
destination SP, if not, redirect and display the friendly names of the 
attributes with their value to the user, requesting consent over the entire set.
- Once consent is given, add some metadata attributes to the assertion before 
it is sent.

Original comment by relaxno...@gmail.com on 12 Aug 2010 at 12:09

GoogleCodeExporter commented 9 years ago 
one more high-level goal:
- focus on the SAML 2.0 proxying functionality (through Scoping or 
URL-encoding); that sets this project apart from the simpleSAMLphp initiative; 
the usual IDP and SP functions and the amount of application integration 
involved in implementation those functions would rather be left to simpleSAMLphp

Original comment by hans.zandbelt@gmail.com on 12 Aug 2010 at 1:11