I ask this because I have a website that offer a portal to several customers, each which accesses the portal by a different host name. Also each customer has their own theme with their own logo and colors. I don’t really want to substitute a generic login at the idP but would prefer to continue to have this application collect the credentials.
I realize collecting creds at the sP probably defeats the security of SAML, but nonetheless I believe it would be secure enough for our needs at this time (and this is a temporary solution anyway… we will be implementing a more standard approach and do away with this; this is just to get us by for a little while). Looking for any helpful suggestions or alternative approaches. Thanks!
This isn’t supported by the SAML specification or our product.
Most end users wouldn’t, and certainly shouldn’t, feel comfortable entering their credentials for one web site (IdP) on a completely different web site (SP).
You would also have compatibility issues as most, if not all, other SAML offerings don’t provide this support either.
If the IdP and SP are both in your control, you could support this using a proprietary solution, assuming you and your customers understand and accept the security risks.
[quote][/quote]
This isn't supported by the SAML specification or our product.
Most end users wouldn't, and certainly shouldn't, feel comfortable entering their credentials for one web site (IdP) on a completely different web site (SP).
You would also have compatibility issues as most, if not all, other SAML offerings don't provide this support either.
If the IdP and SP are both in your control, you could support this using a proprietary solution, assuming you and your customers understand and accept the security risks.
Most end users wouldn't, and certainly shouldn't, feel comfortable entering their credentials for one web site (IdP) on a completely different web site (SP).
You would also have compatibility issues as most, if not all, other SAML offerings don't provide this support either.
If the IdP and SP are both in your control, you could support this using a proprietary solution, assuming you and your customers understand and accept the security risks.
I appreciate your concern for security, but all websites in question are ours and are all on the same domain.
But regardless of how you feel about that, the point is to offer themed login pages and furthermore to hopefully not have to implement the designs on the idP side.
I understand.
The SAML specification supports sending the requested user’s name in the SAML authn request to the IdP.
Instead of just the user’s name, you could encode this field as their user name and password.
Our SAMLServiceProvider.InitiateSSO API includes an overload that takes SSOOptions.
The SSOOptions.RequestedUserName could be set with the user’s name and their password.
Our SAMLIdentityProvider.ReceiveSSO API includes an overload to receive these SSOOptions.
[quote][/quote]
I understand.
The SAML specification supports sending the requested user's name in the SAML authn request to the IdP.
Instead of just the user's name, you could encode this field as their user name and password.
Our SAMLServiceProvider.InitiateSSO API includes an overload that takes SSOOptions.
The SSOOptions.RequestedUserName could be set with the user's name and their password.
Our SAMLIdentityProvider.ReceiveSSO API includes an overload to receive these SSOOptions.
The SAML specification supports sending the requested user's name in the SAML authn request to the IdP.
Instead of just the user's name, you could encode this field as their user name and password.
Our SAMLServiceProvider.InitiateSSO API includes an overload that takes SSOOptions.
The SSOOptions.RequestedUserName could be set with the user's name and their password.
Our SAMLIdentityProvider.ReceiveSSO API includes an overload to receive these SSOOptions.
Ah... that would be great if I had the latest version of the code. Unfortunately the version I have doesn't have this property.
I had wanted to centralize authentication from multiple websites into one Identity Provider, but I ended up just deciding to let each one be its own idP and use idP initiated SSO to the new site for now. Oh well... not really how I wanted to do it but it meets the need for now and we'll likely end up redoing it more properly later anyway.
Thanks for the suggestion anyhow.
You’re welcome.