Hi Devs, Why do we need $subject?
*How it works now :* Currently Identity Server search for query parameter named "tenantDomain" in the SAML request and set the tenant if that parameter is available. If the "tenantDomain" parameter not included in the SAML request, it will process the Issuer element of the SAML Request to retrieve tenant domain. > ie : If the issuer value is "[email protected]", Identity Server > assumes this is a request sent from a Service Provider (named as " > travelocity.com") in "foo.com" tenant. *What are the facts :* Identity Server have above capability from v5.0.0. AFAIR, followings are the facts we considered adding on that capability. 1. Identity Server supports multi-tenancy which means different tenants of IS will act as independent Identity Providers. 2. Earlier versions of Identity Server (before 5.0.0), it used to pick tenant from username after authenticating the user. 3. In Identity Server 5.0.0 we added a capability that each SP can define its own authentication flow. For example, - App1 can be configured to login with username password and - App2 can be configured to have two steps login where first step asks for login with facebook and as the second step its prompt to enter a pin. 4. Now it should pick the service provider configurations (before authentication) to decide authentication flow. To retrieve service provider configurations it should know the tenant domain information somehow. So now server cannot retrieve tenant domain as #2. 5. This lead to introducing tenant specific endpoints. Each tenant\IdP will have its own SAML endpoint. ie, - SAML requests to "https://localhost:9443/samlsso" endpoint considered as SAML requests for super tenant - SAML requests to " https://localhost:9443/samlsso?tenantDomain=foo.com" endpoint considered as SAML requests for "foo.com" tenant. 6. From SPs perspective its needed to provide IdP's SAML endpoint as " https://localhost:9443/samlsso?tenantDomain=foo.com" if it want to use " foo.com" tenant as its IdP. 7. When SP build the SAML Request it normally set the Destination property in the request which normally set as the IdP's SAML endpoint. For example, - Destination="https://localhost:9444/samlsso?teantDomain=foo.com" 8. As per our destination validation logic its doing a direct string match against the "IdentityProviderURL" in the identity.xml with the destination property. So in order to pass destination validation we can set "IdentityProviderURL" as https://localhost:9444/samlsso?teantDomain=foo.com" but this does not scale as a different tenant required put their own url as "IdentityProviderURL" in identity.xml but only one URL we can define in the identity.xml. This is the reason we implement $subject I guess. So instead of specifying tenant domain from IdP url in the Service Provider side, it appends "@ foo.com" part to the issuer value (SP Entity ID). So we process issuer value in the Identity Server to pick tenant domain. Are there any other reasons to $subject. If we are processing the issuer to pick tenant domain, only to avoid destination validation errors, what we could have been done is improve the validation logic rather manipulating issuer. WDYT? Thanks, Darshana. -- Regards, *Darshana Gunawardana*Senior Software Engineer WSO2 Inc.; http://wso2.com *E-mail: [email protected] <[email protected]>* *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
