Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Your understanding is not completely correct. In Step 1, the SAML TAI does indeed deduce the user name from the SAML response. It does this in a manner determined by the <a href="http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.multiplatform.doc/info/ae/ae/rwbs_samltaiproperties.html" rel="nofollow">SAML TAI custom properties</a>. Step 2 is where I believe you begin to stray. The term "application" is too general here. The SAML TAI checks the WAS registry configured for the security domain for an existing user if you configure the <code>idMap</code> custom property to be <code>localRealm</code>. Otherwise the assumption is <code>idAssertion</code> which creates an <em>ephemeral user</em>, one that exists in the JAAS subject but not the registry.</p> <p>I do not recall which WAS application library contains the SAML TAI code. This knowledge is not required to use the SAML TAI. If your intention is to reverse compile the SAML TAI code in order to clarify your understanding, I'd like to encourage you to first study a <a href="http://www.ibm.com/developerworks/websphere/techjournal/1307_lansche/1307_lansche.html" rel="nofollow">developerWorks article on the SAML TAI</a> that presents common web-based SSO scenarios with WAS. It describes how one configures the SAML TAI custom properties to undertake various use cases. It also discusses how the SAML TAI leverages new general TAI capabilities that allow it to hook into the security model at more than one stage.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload