The document describes the results of Virginia Tech's testing related to InCommon Silver Assurance. We use CAS for our SSO environment, so the context for all our testing leveraged CAS for authentication and the RemoteUser login handler in the Shibboleth IDP. Instructions for configuring an environment similar to ours can be found at: https://wiki.jasig.org/display/CASUM/Shibboleth-CAS+Integration. All of this testing occurred with the help of the folks at CILogin using their test SP.
Use Case Testing
While the assurance use cases lay out several work flows, this document will concentrate on how the IDP functions. Ultimately the behavior of requires or prefers in those use cases is dictated entirely by the SP.
...
The authnMethod request attribute must be set on the Shibboleth IDP for all requests. Failure to do so will result in incorrect assertions apparently due to advertising silver in the response authnContext.
Configuration
We present some important configuration considerations relating to the above testing. It's important to note that leveraging our existing CAS SSO infrastructure is a vital aspect of our approach to assurance, and many of the following considerations are specific to our architecture. We hope that by sharing some important specific configuration matters, some general concerns may be distilled for other IDM architectures.
IdP Configuration
CAS is the authentication provider for our IdP, so all authentication methods map to a single login handler. We use the IdP's delegated authentication handler, i.e. RemoteUser, to integrate with CAS.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<!-- Remote User handler for CAS support -->
<LoginHandler xsi:type="RemoteUser">
<AuthenticationMethod>
urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</AuthenticationMethod>
<AuthenticationMethod>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</AuthenticationMethod>
<AuthenticationMethod>
http://id.incommon.org/assurance/bronze-test
</AuthenticationMethod>
<AuthenticationMethod>
http://id.incommon.org/assurance/silver-test
</AuthenticationMethod>
</LoginHandler>
|
The order of advertised authentication methods within the handler is apparently irrelevant, yet we list them in order of increasing strength.
The key component of CAS-IdP integration from the perspective of InCommon Assurance is a custom servlet filter that maps a SAML AuthenticationMethod attribute sent by CAS into an AuthnContext to be asserted by the IdP. The source for this component, AssertionAttributeAuthenticationMethodFilter, is available for review.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<filter>
<filter-name>AssertionAttributeAuthenticationMethodFilter</filter-name>
<filter-class>
edu.vt.middleware.shib.cas.AssertionAttributeAuthenticationMethodFilter
</filter-class>
<init-param>
<param-name>authMethodAttribute</param-name>
<param-value>samlAuthenticationStatement::authMethod</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>AssertionAttributeAuthenticationMethodFilter</filter-name>
<url-pattern>/Authn/RemoteUser</url-pattern>
</filter-mapping>
|
The key integration configuration item between CAS and Shib is the value of the authMethodAttribute parameter. The particular value we have chosen, samlAuthenticationStatement::authMethod, corresponds to the value that the CAS components use for the SAML 1.1 AuthenticationMethod attribute. It's important to note that corresponding configuration is required in CAS to set the AuthenticationMethod appropriately so it can be consumed by the IdP.
CAS Configuration
We had already invested a significant amount of engineering effort on supporting multiple credentials in our CAS SSO solution prior to the InCommon Assurance program. We leveraged this existing assurance infrastructure to bridge our internal credential LOA values onto InCommon Assurance identifiers. The SAML 1.1 support in CAS provided a convenient mechanism to indicate authentication method to clients, in this case the IdP. It was simply a matter of specifying how InCommon Assurance identifiers map onto particular authentication credentials. The following configuration snippet demonstrates this:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<bean id="authenticationManager" class="org.jasig.cas.authentication.AuthenticationManagerImpl">
<snip/>
<!--
Populates the Authentication object with data about the authenticated
principal or other circumstances of the authentication event.
The Authentication object is an attribute or the TGT, so data in the
Authentication can be provided to CAS clients at service ticket validation
time.
-->
<property name="authenticationMetaDataPopulators">
<list>
<bean id="nistLevelPopulator"
class="edu.vt.middleware.cas.authentication.metadata.LevelOfAssuranceMetaDataPopulator"
p:attributeName="LOA">
<property name="calculators">
<list>
<ref bean="usernameNistLevelCalculator"/>
<ref bean="pdcNistLevelCalculator"/>
</list>
</property>
</bean>
<bean id="eduPersonAssurancePopulator"
class="edu.vt.middleware.cas.authentication.metadata.LevelOfAssuranceMetaDataPopulator"
p:attributeName="samlAuthenticationStatementAuthMethod">
<property name="calculators">
<list>
<ref bean="usernameEduPersonAssuranceCalculator"/>
<ref bean="pdcEduPersonAssuranceCalculator"/>
</list>
</property>
</bean>
</list>
</property>
<snip/>
</bean>
<!--
URNs taken from
http://www.oasis-open.org/committees/download.php/28706/sstc-saml-loa-authncontext-profile-draft-01.pdf
-->
<bean id="usernameNistLevelCalculator"
class="edu.vt.middleware.cas.authentication.metadata.AuthIdLevelOfAssuranceCalculator"
p:guestAccountLevel="urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800-63:v1-0-2:1"
p:pidAccountLevel="urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800-63:v1-0-2:2" />
<bean id="pdcNistLevelCalculator"
class="edu.vt.middleware.cas.authentication.metadata.PDCLevelOfAssuranceCalculator"
p:defaultLevel="urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800-63:v1-0-2:1">
<property name="oidLevelMap">
<!-- Must list in order of descending value -->
<map>
<!-- Medium Silver -->
<entry key="1.3.6.1.4.1.6760.5.2.2.5.1" value="urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800-63:v1-0-2:4" />
<!-- Medium Bronze -->
<entry key="1.3.6.1.4.1.6760.5.2.2.4.1" value="urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800-63:v1-0-2:4" />
<!-- Basic -->
<entry key="1.3.6.1.4.1.6760.5.2.2.3.1" value="urn:oasis:names:tc:SAML:2.0:post:ac:classes:nist-800-63:v1-0-2:2" />
</map>
</property>
</bean>
<bean id="usernameEduPersonAssuranceCalculator"
class="edu.vt.middleware.cas.authentication.metadata.AuthIdLevelOfAssuranceCalculator"
p:guestAccountLevel="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport"
p:pidAccountLevel="urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport" />
<bean id="pdcEduPersonAssuranceCalculator"
class="edu.vt.middleware.cas.authentication.metadata.PDCLevelOfAssuranceCalculator"
p:defaultLevel="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified">
<property name="oidLevelMap">
<!-- Must list in order of descending value -->
<map>
<!-- Medium Silver -->
<entry key="1.3.6.1.4.1.6760.5.2.2.5.1" value="http://id.incommon.org/assurance/silver" />
<!-- Medium Bronze -->
<entry key="1.3.6.1.4.1.6760.5.2.2.4.1" value="http://id.incommon.org/assurance/bronze" />
</map>
</property>
</bean>
<snip/>
|
The *Calculator components encapsulate the details of examining credentials, which in the case of X.509 certificates is substantial, and computing an LOA value. We release NIST-like LOA values for internal use, and InCommon Assurance identifiers for IdP integration. The eduPersonAssurancePopulator bean, in particular, is responsible for communicating that value to CAS clients such as the IdP via the SAML protocol AuthenticationMethod attribute.