Is it possible to hit the IdP login form directly from a browser?

[Yaowen Tu]

Thanks Scott. I am thinking about extend our IdP SingleSIgnOn redirect end
point. I want to get some feedbacks before I continue.

Suppose our IdP use "username and password" as authentication method. The
SingleSignOn request now accepts SAMLRequest and RelayState as two
parameters. I am thinking to extend it by also accepting "username" and
"password". In this way if the username and password are provided, IdP will
automatically tries to login instead of showing login screen.

What I want to know is:
1) Does it violets with SAML protocols. To me seems that it is not breaking
anything currently working. I understand that inter-op is an issue.

2) How hard is it to extend the Shib IdP to work like this? What modules or
components I may need to modify?

3) Is there any security concerns?

Thanks,
Yaowen


On Tue, Sep 4, 2012 at 5:45 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 9/4/12 7:39 PM, "Yaowen Tu" <yaowen.tu at gmail.com> wrote:
> >
> >Are you familiar with this approach? Is it widely used? It seems that in
> >order to continue with this approach the critical part is that SP needs
> >to support SAML and OAuth, and native client needs to support OAuth.
>
> More or less. OAuth, at least the new version, is not "one thing" you can
> support. It's closest analogy is WS-Trust. It's a very complex design
> pattern involving a ton of options and open buckets that you have to
> define and profile. If you don't do that, you don't get interop. You will
> not get agreement on my characterization, but I won't be convinced I'm
> wrong any more than its proponents will admit they are, so time will tell.
>
> >I also see some articles about combining SAML and OAuth together, any
> >comments with it?
>
> Usually they're combined because there's a web login step that is
> orthogonal to OAuth and can be done with any mechanism, from basic-auth to
> SAML to OpenID. It doesn't matter. Combining them more deeply tends to be
> complex, sometimes ends up breaking SAML assertion rules, and probably
> won't be very interoperable. They essentially overlap, which means
> combining them tends to be as much political as useful, and sometimes gets
> quite odd.
>
> >Comparing with ECP approach, what are the pros and cons?
>
> Without getting into the technical arguments, ECP is a direct adaptation
> of the SSO flow of getting a short-lived token with the user's
> credentials, submitting it, and usually getting a session back with a
> cookie. OAuth tends to rely on obtaining longer-lived bearer tokens to
> store in the client that are like cookies but not implemented as cookies.
> OAuth is more amenable to mobile tricks involving use of web browsers to
> do the login step, although you can do the same kind of thing with ECP
> with some work.
>
> >I also remember somewhere in the wiki I saw that in the new SAML version,
> >you are going to further standardize the ECP method, especially the
> >interaction between client and IdP for authentication. Any more details?
>
> Standardizing the interaction is a conformance issue. The standard can't
> mandate how people do authentication. All it can do is specify what
> implementations have to support so that two independent implementations
> are guaranteed to have something in common. None of that addresses
> deployment choices, and any time a client is involved, the deployment
> choice problem tends to supersede the implementation choice issue.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120910/88193701/attachment.html