Hi,<br><br>This might be a dumb question, or something that violets to the SAML design principals. I just want to see how we designed the IdP to treat this use case.<br><br>In a usual way, end user will access a protected page in SP first, and after some redirection, IdP displays a login page, suppose the login page is: "<a href="https://localhost/idp/Authn/UserPassword">https://localhost/idp/Authn/UserPassword</a>". After that IdP establishes a session with the browser.<br>
<br>What if user directly access "<a href="https://diamond.actuate.com/idp/Authn/UserPassword">https://diamond.actuate.com/idp/Authn/UserPassword</a>"? I have tried with Shib IdP, and it shows some error which is what I expected. I just want to know why this use case is invalid?<br>
<br>Based on my experience with SAML( very limited ), I think it make sense that user login to IdP first to establish a valid session, then later on he can access some SP protected resources without entering the password. There should be some reason that I missed to explain the potential problem for this approach.<br>
<br><br>Another related question is, I know there is something called "IdP-initiated" SSO, which is user hit <strong>/idp/profile/SAML2/Unsolicited/SSO </strong>directly, then IdP redirect to a login page. Do we support something like this to automatically get the user name and password?<br>
<strong>/idp/profile/SAML2/Unsolicited/SSO?username=user1&password=password1</strong><br clear="all"><br>I have been thinking about the reason of it. Is it because that SAML doesn't actually define how IdP authenticate a user? So it is every IdP's responsibility and interoperability is an issue? What else?<br>
<br><br>Best, <br>Yaowen<br>