<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Yaowen,</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">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></span></blockquote><div><br></div><div>There is no real problem with it. The Shibboleth IdP just doesn't directly address this use case; SSO sessions are always established in the context of authenticating to something other than the IdP. You could do this implementation if you wanted to.</div><div><br></div><div>I'd suggest doing it through a dedicated handler rather than making the authentication handler "just assume" the user wanted to authenticate and go nowhere. You'll also probably want some meaningful workflows on the page that results from a successful authentication.</div><div><br></div><div>I would probably just implement this as authentication to a portal, though. Because you want meaningful workflows at the end, why not just achieve SSO that way?</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><br>Another related question is, I know there is something called "IdP-initiated" SSO, which is user hit<span class="Apple-converted-space"> </span><strong>/idp/profile/SAML2/Unsolicited/SSO<span class="Apple-converted-space"> </span></strong>directly, then IdP redirect to a login page. Do we support something like this to automatically get the user name and password?<br> <span class="Apple-converted-space"> </span><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></span></blockquote></div><br><div>No, the IdP doesn't support this, and putting sensitive data in a GET request is not really a best practice.</div><div><br></div><div>Take care,</div><div>Nate.</div></body></html>