home


The Corto code is at http://code.google.com/p/corto/

Corto functional description

Corto is a PHP open source software package for web single sign-on across or within organizational boundaries based on the SAML2 specification. It allows sites to make informed authorization decisions for individual access of protected online resources. It supports individual user's informed consent, as part of the attribute release process.


Ordered map representation of SAML messages and metadata

Corto's basic architecture is a simple ordered map representation (PHP array) of SAML assertions, requests and responses as well as of metadata. The "real" SAML xml is converted to arrays coming in to Corto and vice versa on its way out. 


SAML system entities can be idp's or sp's and in Corto they are always both ie. they are always bridges/proxies. This is because a sp have an idp interface to present its assertions to the application proper and an idp have a sp side to get the user authenticated. One might think of these interfaces as "intra-organisational" in that they do not need access to the same metadata and pki as the federation visible interfaces. To make these interfaces simpler to develop (in the app and auth mechanism) but stil allowing access to the full saml message Corto can send and receive them in two new bindings - JSON-POST and JSON-Redirect, yet to be standardized. They are always encrypted using a simple shared secret schema. 


Corto is thus always "remote" in the sense that applications are always seen as remote sp's and authentication mechanisms are always seen as remote idp's. 


Corto supports the standard bindings: HTTP-Redirect, HTTP-POST, HTTP-POST-SimpleSign, HTTP-Artifact, URI, SOAP.




Corto has a notion of co-hosted system entities - communication between co-hosted entities is done by an internal binding mechanism (ie. no browser involvement) for performance reasons i.e. saving redirects in attribute collector scenarios.


Corto configuration with metadata

Corto is meant to be used in an environment where metadata is handled by a metadata management system (MDMS) e.g. JANUS. All configuration of SAML entities is done by importing SAML2 metadata. Corto specific configuration is specified in metadata using SAML2 extensions for entity attributes which must be handled by the MDMS.



The metadata used by Corto may be made available by either using push or pull methods applied to either local files or imported from remote sites, using urls. To allow metadata to specify 'private' information (e.g. private keys etc.) for a given entity, metadata can be merged from multiple sources. 


Meaningless URLs

Service urls in Corto are 'meaningless' in the sense that Corto looks up the entityID, binding and service using the full url specified in metadata without looking at the individual parts of the url. This way any entity may be associated with an arbitrary location as long as Corto is handling the 'call'. This allows Corto to handle multiple entities per installation.




When importing a metadata set it is possible to specify a tag in order partition the imported metadata into separate named and independant 'federations'. This allows Corto to handle multiple federations per installation. It is not possible to do inter-federation bridging as entitityIDs are only guarantied to be unique per federation (not globally) but might be visible across the bridge in the RequesterID and AuthenticationAuthority elements.


Single Log out

Corto supports single-logout using all relevant bindings (HTTP-Redirect, HTTP-POST, HTTP-POST-SimpleSign, HTTP-Artifact, SOAP).


Extension point for users' informed consent 

It is possible per IdP to specify a service external to Corto which handles user's informed consent or any other user involvement, using front channel communication, before sending the response to the requesting service provider.


Extension for filtering

It is possible to specify per entity filters (external or internal) that have access to the full requests and responses in addition to the obvious assertions and attributes.


SAML2 authentication request scoping

Corto supports the SAML2 scoping element which allows service providers to build their own discovery services and target individual IdP's even though hub-and-spoke federations only have a single entry-point for authentication requests.


Transparent proxying

To support service providers which do not support the SAML2 scoping element, and thus expects to send authentication requests directly to the IdP, Corto employs transparent proxying by providing a proxy-IdP for each 'back-end-IdP' at a common bridge. It may also be used to collect and store attributes which are to be made available using non-SAML channels e.g. LDAP and OpenSocial. The federation-hub is seen as a single service provider by the back-end IdPs and therefore Corto supports different entity IDs on each side on the hub/bridge.


Virtual IdP / Attribute collection

A virtual IdP is a front end IdP, provided by Corto, for multiple back-end-IdPs. The virtual IdP presents to the service provider a set of merged attributes from a number of scoped requests to the back-end IdPs. 





Handling of signing, encryption, public and private keys

Corto supports both signing and encryption as per the SAML2 specification. The JSON bindings use an OpenSSL compatible encryption (SALTED__<8-chars salt>EncryptedMessage…) using AES-256-CBC and a shared key phrase.


Thick and thin proxying

Corto acting as a federation hub can be used as either a thick or thin proxy, configured per IdP. A thick proxy caches the assertion from an IdP and uses that for answering subsequent non-scoped requests. A thin proxy always relays requests to the back-end IdP and, in turn, the responses to the service provider.


Unsolicited responses

Corto supports unsolicited responses. In the case of a thin proxy this can be seen as 'seeding' the discovery service with the ID of the users' IdP. This is typically used by the IdP's local single-sign-on system as part of the login procedure, albeit transparent to the user. The aim is to enhance the user experience when going to federated services in that no discovery service will be nessecary.




Subpages (1): Corto partners