The native SP is written in C++ and is integrated with various web servers directly using the proprietary APIs they provide. A mix of native server integration and portable configuration is provided (though native support is mostly confined to the Apache version). Most of the portable configuration is handled by various files in the
/etc/shibboleth directory, but the web server configuration itself determines some of the SP's behavior.
Most of the native SP's core functionality is defined in
shibboleth2.xml. Read that topic for a detailed breakdown. Key subcomponents are also listed below.
Metadata defines a partner site's capabilities, endpoints, keys, and other useful information. The Shibboleth software implicitly trusts the metadata it is given and uses it as a basis for all of its runtime decisions and choices.
Trust engines provide the basis for authenticating messages from partner sites and securing the system in a "real world" sense.
The SP loads its own keys and certificates (not to be confused with SSL certificates used by web servers) using these plugins.
The SP can resolve attributes from external sources (in addition to those it receives as part of SSO).
The SP extracts attributes it receives from SAML assertions and prepares them for use by web applications using AttributeExtractor plugins. The default version is configured using an XML file such as
Rules are applied to extracted and resolved attributes using attribute filter policies. The default version used by the native SP shares the same basic language and most of the features of the Java AFP implementation, and is configured with the
Some mandatory configuration is always required to integrate the SP with a web server. Some servers also support a degree of "native" integration enabling the SP to be partly controlled from the web server's own configuration file(s).
Microsoft's IIS (at least pre-7.0) does not provide for any significant native configuration capability, and no GUI integration into the IIS console is supported at this time.