FAQ
Hello everybody! [Well, mostly JayK and Tatsuhiko Miyagawa].

I think I have a working modernized (to the current bleeding edge of
the Auth system) OpenID Credential package:
Catalyst::Authentication::Credential::OpenID. Before I work on docs
and trying to making it tested and bomb-proof I want to check with
all y'all.

It's based on the second generation
Catalyst::Plugin::Authentication::Credential::OpenID from Tatsuhiko
Miyagawa and all the new stuff from Jay Kuri.

So instead of
$c->authenticate_openid()
you have realm based auth
$c->authenticate({ openid_identifier => $claimed_uri }, "openid")

I considered including the legacy parts of CPA::Credential::OpenID,
specifically authenticate_openid(), but have come out against it as
too confusing without a big enough user base to justify it. Contrary
arguments are welcome.

The docs and error feedback will note that the store class Null (with
user class User::Hash) is the only built-in supported one. I plan to
add a namespace-preserving data slurp on the OpenID stuff (though I
haven't looked at how/where this will work so it might be wishful
thinking for now) so that arbitrary things like Simple Registration
will be brought in as a sub-hash-ref instead of multiple key-val
pairs at the top of the user object. Perhaps this is where a user
class for OpenID should happen; it would follow the OpenId spec and
refuse to find_user unless the required fields were present.

So, that would mean the package (with two classes, credential and
user) would be released together under the otherwise empty namespace
Catalyst::Authentication::OpenID(???).

Also, OpenID stuff can be difficult, to put it mildly, to debug so
I'd like to put in lots of debug statements. What is (or which module
represents) the current best practice for per module debug handling
so it can be toggled (in the config?)?

Related:
http://openid.net/specs/openid-simple-registration-extension-1_0.html

Do the name change and general direction sound right?

-Ashley
--
PS: ?? to that thread.

Search Discussions

  • Jay Shirley at Apr 6, 2008 at 4:44 am

    On Wed, Apr 2, 2008 at 9:38 PM, Ashley wrote:
    Hello everybody! [Well, mostly JayK and Tatsuhiko Miyagawa].

    I think I have a working modernized (to the current bleeding edge of the
    Auth system) OpenID Credential package:
    Catalyst::Authentication::Credential::OpenID. Before I work on docs and
    trying to making it tested and bomb-proof I want to check with all y'all.

    It's based on the second generation
    Catalyst::Plugin::Authentication::Credential::OpenID from Tatsuhiko Miyagawa
    and all the new stuff from Jay Kuri.

    So instead of
    $c->authenticate_openid()
    you have realm based auth
    $c->authenticate({ openid_identifier => $claimed_uri }, "openid")

    I considered including the legacy parts of CPA::Credential::OpenID,
    specifically authenticate_openid(), but have come out against it as too
    confusing without a big enough user base to justify it. Contrary arguments
    are welcome.

    The docs and error feedback will note that the store class Null (with user
    class User::Hash) is the only built-in supported one. I plan to add a
    namespace-preserving data slurp on the OpenID stuff (though I haven't looked
    at how/where this will work so it might be wishful thinking for now) so that
    arbitrary things like Simple Registration will be brought in as a
    sub-hash-ref instead of multiple key-val pairs at the top of the user
    object. Perhaps this is where a user class for OpenID should happen; it
    would follow the OpenId spec and refuse to find_user unless the required
    fields were present.

    So, that would mean the package (with two classes, credential and user)
    would be released together under the otherwise empty namespace
    Catalyst::Authentication::OpenID(???).

    Also, OpenID stuff can be difficult, to put it mildly, to debug so I'd like
    to put in lots of debug statements. What is (or which module represents) the
    current best practice for per module debug handling so it can be toggled (in
    the config?)?

    Related:
    http://openid.net/specs/openid-simple-registration-extension-1_0.html

    Do the name change and general direction sound right?

    -Ashley
    --
    PS: ?? to that thread.
    Hey Ashley,

    This sounds like the right direction to me. I'm eager to see the new
    work, as well. Do you have a dev package available? Also, if you
    need proper commit bits to the main Catalyst repos please let me know
    and I'll get that sorted out for you.

    I'm getting ready to start working on another OpenID consumer
    application, and would like to use your work.

    Thanks,
    -Jay
  • Ashley Pond V at Apr 6, 2008 at 5:11 am

    On Apr 5, 2008, at 8:44 PM, J. Shirley wrote:
    On Wed, Apr 2, 2008 at 9:38 PM, Ashley wrote:
    Hello everybody! [Well, mostly JayK and Tatsuhiko Miyagawa].

    I think I have a working modernized (to the current bleeding edge
    of the
    Auth system) OpenID Credential package:
    Catalyst::Authentication::Credential::OpenID. Before I work on
    docs and
    trying to making it tested and bomb-proof I want to check with all
    y'all.

    It's based on the second generation
    Catalyst::Plugin::Authentication::Credential::OpenID from
    Tatsuhiko Miyagawa
    and all the new stuff from Jay Kuri.

    So instead of
    $c->authenticate_openid()
    you have realm based auth
    $c->authenticate({ openid_identifier => $claimed_uri }, "openid")
    This sounds like the right direction to me. I'm eager to see the new
    work, as well. Do you have a dev package available?
    Great. I worked on it a bunch today and got a working test app with
    it running a provider and a consumer along with some plain text
    inline Auth so it can test itself. I managed to use some of JRock's
    test stuff + some of JK's to write a live test that I *think* is
    okay. It's difficult to know because the test server has to run with
    forking so it can answer its own requests but it's passing in my env
    on OS X at least. It's minimal but there is a working OpenID server
    example in the t/TestApp code.

    I'm trying to do some reasonable POD right now and I was hoping to
    get a slightly messy 0.01 on the CPAN tonight (missing the OpenID
    store class which I'd really like to have but that's another day+ to
    write and test which might push it off a week or more). I have my own
    svn server but since it's just me, it's messy with poor revision
    messages and I check in broken stuff so I can get it between my
    machines... that said, if you can't wait or I'm too slow: http://
    dev.perlperl.com/cpan/trunk/CA-OpenID/ (that should be open for
    checkouts; I just flipped it to public).
    Also, if you need proper commit bits to the main Catalyst repos
    please let me know
    and I'll get that sorted out for you.
    I would love that. If nothing else, I'd be glad to tackle typo/small-
    fish bugs and help update some of the document drift in
    authentication stuff.
    I'm getting ready to start working on another OpenID consumer
    application, and would like to use your work.

    I hope you do and please if any room for improvement jumps out at
    you, don't be shy. I worked a bunch with OpenID last year on a
    contract but I'm no guru with it.

    -Ashley
  • Jay K at Apr 7, 2008 at 6:30 pm
    Hi Ashley,

    Sorry for the delay, It sounds quite interesting. Are you working off
    of the auth module in svn at the moment, or the released version. I
    ask because there are changes in svn that might make it easier to
    implement. I'm in the process of documenting those changes for a
    release soon. Namely, the realm has much more control (more hook
    points) in the auth process - might be useful.

    Anyway - let me know if I can help in any way.

    Jay

    On Apr 5, 2008, at 10:11 PM, Ashley wrote:
    On Apr 5, 2008, at 8:44 PM, J. Shirley wrote:
    On Wed, Apr 2, 2008 at 9:38 PM, Ashley wrote:
    Hello everybody! [Well, mostly JayK and Tatsuhiko Miyagawa].

    I think I have a working modernized (to the current bleeding edge
    of the
    Auth system) OpenID Credential package:
    Catalyst::Authentication::Credential::OpenID. Before I work on
    docs and
    trying to making it tested and bomb-proof I want to check with all
    y'all.

    It's based on the second generation
    Catalyst::Plugin::Authentication::Credential::OpenID from
    Tatsuhiko Miyagawa
    and all the new stuff from Jay Kuri.

    So instead of
    $c->authenticate_openid()
    you have realm based auth
    $c->authenticate({ openid_identifier => $claimed_uri }, "openid")
    This sounds like the right direction to me. I'm eager to see the new
    work, as well. Do you have a dev package available?
    Great. I worked on it a bunch today and got a working test app with
    it running a provider and a consumer along with some plain text
    inline Auth so it can test itself. I managed to use some of JRock's
    test stuff + some of JK's to write a live test that I *think* is
    okay. It's difficult to know because the test server has to run with
    forking so it can answer its own requests but it's passing in my env
    on OS X at least. It's minimal but there is a working OpenID server
    example in the t/TestApp code.

    I'm trying to do some reasonable POD right now and I was hoping to
    get a slightly messy 0.01 on the CPAN tonight (missing the OpenID
    store class which I'd really like to have but that's another day+ to
    write and test which might push it off a week or more). I have my
    own svn server but since it's just me, it's messy with poor revision
    messages and I check in broken stuff so I can get it between my
    machines... that said, if you can't wait or I'm too slow: http://dev.perlperl.com/cpan/trunk/CA-OpenID/
    (that should be open for checkouts; I just flipped it to public).
    Also, if you need proper commit bits to the main Catalyst repos
    please let me know
    and I'll get that sorted out for you.
    I would love that. If nothing else, I'd be glad to tackle typo/small-
    fish bugs and help update some of the document drift in
    authentication stuff.
    I'm getting ready to start working on another OpenID consumer
    application, and would like to use your work.

    I hope you do and please if any room for improvement jumps out at
    you, don't be shy. I worked a bunch with OpenID last year on a
    contract but I'm no guru with it.

    -Ashley


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    ---
    "Those who can make you believe absurdities can make you commit
    atrocities." --Voltaire
  • Ashley Pond V at Apr 7, 2008 at 7:01 pm

    On Apr 7, 2008, at 10:30 AM, Jay K wrote:
    Hi Ashley,

    Sorry for the delay, It sounds quite interesting. Are you working off
    of the auth module in svn at the moment, or the released version. I
    ask because there are changes in svn that might make it easier to
    implement. I'm in the process of documenting those changes for a
    release soon. Namely, the realm has much more control (more hook
    points) in the auth process - might be useful.

    Anyway - let me know if I can help in any way.
    Working from the CPAN version.

    http://search.cpan.org/dist/Catalyst-Authentication-Credential-OpenID/
    (Ignore the extra "Documentation" link, I left a trash copy of the
    file in there and need to get it out; I'll try tonight when I've got
    time; I notice another mistake -- I left the store class in the
    sample config but it doesn't exist yet.)

    I'd love to see your new stuff. I'll take a look later. I am
    already basically using the realm for everything. Don't know
    what the new looks like but the old was pretty easy to follow
    and I was grateful for the internals info you put in the POD.

    The only current real configuration option, for example, is that
    you can set your own user agent and pass it arguments. From the POD-

    Plugin::Authentication:
    default_realm: members
    realms:
    openid:
    credential:
    class: OpenID
    ua_class: LWPx::ParanoidAgent
    ua_args:
    whitelisted_hosts:
    - 127.0.0.1
    - localhost
    On Apr 5, 2008, at 10:11 PM, Ashley wrote:
    On Apr 5, 2008, at 8:44 PM, J. Shirley wrote:
    On Wed, Apr 2, 2008 at 9:38 PM, Ashley wrote:
    Hello everybody! [Well, mostly JayK and Tatsuhiko Miyagawa].

    I think I have a working modernized (to the current bleeding edge
    of the
    Auth system) OpenID Credential package:
    Catalyst::Authentication::Credential::OpenID. Before I work on
    docs and
    trying to making it tested and bomb-proof I want to check with all
    y'all.

    It's based on the second generation
    Catalyst::Plugin::Authentication::Credential::OpenID from
    Tatsuhiko Miyagawa
    and all the new stuff from Jay Kuri.

    So instead of
    $c->authenticate_openid()
    you have realm based auth
    $c->authenticate({ openid_identifier => $claimed_uri }, "openid")
    This sounds like the right direction to me. I'm eager to see the
    new
    work, as well. Do you have a dev package available?
    Great. I worked on it a bunch today and got a working test app with
    it running a provider and a consumer along with some plain text
    inline Auth so it can test itself. I managed to use some of JRock's
    test stuff + some of JK's to write a live test that I *think* is
    okay. It's difficult to know because the test server has to run with
    forking so it can answer its own requests but it's passing in my env
    on OS X at least. It's minimal but there is a working OpenID server
    example in the t/TestApp code.

    I'm trying to do some reasonable POD right now and I was hoping to
    get a slightly messy 0.01 on the CPAN tonight (missing the OpenID
    store class which I'd really like to have but that's another day+ to
    write and test which might push it off a week or more). I have my
    own svn server but since it's just me, it's messy with poor revision
    messages and I check in broken stuff so I can get it between my
    machines... that said, if you can't wait or I'm too slow: http://
    dev.perlperl.com/cpan/trunk/CA-OpenID/
    (that should be open for checkouts; I just flipped it to public).
    Also, if you need proper commit bits to the main Catalyst repos
    please let me know
    and I'll get that sorted out for you.
    I would love that. If nothing else, I'd be glad to tackle typo/small-
    fish bugs and help update some of the document drift in
    authentication stuff.
    I'm getting ready to start working on another OpenID consumer
    application, and would like to use your work.

    I hope you do and please if any room for improvement jumps out at
    you, don't be shy. I worked a bunch with OpenID last year on a
    contract but I'm no guru with it.

    -Ashley


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/
    catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    ---
    "Those who can make you believe absurdities can make you commit
    atrocities." --Voltaire



    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/
    catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Aristotle Pagaltzis at Apr 8, 2008 at 1:21 am
    Hi Ashley,

    * Ashley [2008-04-07 20:10]:
    is there any way to tell which OpenID provider was used for a
    particular credential? F.ex. a company might use OpenID as its
    SSO mechanism, by setting up an OpenID provider for employees, in
    which case an internal app might want to grant extra trust to
    OpenIDs from that provider (or reject IDs from other providers
    altogether).

    OK, in this particular example you could get away with accepting
    only OpenIDs of a particular form. But delegation is an integral
    part of OpenID and in other similar scenarios on the open web it
    would be interesting to know the provider, not just the identity.

    A quick skim of Net::OpenID::Consumer does not reveal a way to
    get at this, however? is there?

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Tatsuhiko Miyagawa at Apr 8, 2008 at 1:42 am
    Hi,
    On Mon, Apr 7, 2008 at 5:22 PM, Aristotle Pagaltzis wrote:
    A quick skim of Net::OpenID::Consumer does not reveal a way to
    get at this, however? is there?
    There's the identity_server method in Net::OpenID::ClaimedIdentity.

    my $identity = $csr->claimed_identity($claimed_uri)
    or Catalyst::Exception->throw($csr->err);
    my $check_url = $identity->check_url(...);

    I guess this Catalyst auth plugin can inject some callback here before
    calling check_url() to add more trust to some specific provider.


    --
    Tatsuhiko Miyagawa
  • Ashley Pond V at Apr 8, 2008 at 4:04 am

    On Apr 7, 2008, at 5:22 PM, Aristotle Pagaltzis wrote:
    Hi Ashley,

    * Ashley [2008-04-07 20:10]:
    is there any way to tell which OpenID provider was used for a
    particular credential? F.ex. a company might use OpenID as its
    SSO mechanism, by setting up an OpenID provider for employees, in
    which case an internal app might want to grant extra trust to
    OpenIDs from that provider (or reject IDs from other providers
    altogether).

    OK, in this particular example you could get away with accepting
    only OpenIDs of a particular form. But delegation is an integral
    part of OpenID and in other similar scenarios on the open web it
    would be interesting to know the provider, not just the identity.

    A quick skim of Net::OpenID::Consumer does not reveal a way to
    get at this, however? is there?
    That is intriguing. I see Tatsuhiko already mentioned the
    identity_server() method in Net::OpenID::ClaimedIdentity.

    Another thing that could be caught is the spec level of the
    authentication. Unsure where (or if it's already there) but
    should be doable.

    The OpenID store I am planning to write could catch/contain
    these things. How to tie it in to increased/reduced trust
    then? Just in the app? Inline in the realm with "roles" for
    providers? Perhaps-

    $c->assert_roles("https://trusted-provider.org")

    Then things like a tree...
    if $c->check_roles("https://supertrust.net")
    # you get everything
    elsif $c->check_roles("http://okiedokey.com")
    # you're pretty cool
    elsif $c->user_exists and $c->user->"generic_OpenID"
    # you're allowed to vote and all but not XYZ
    else
    $c->res->body("Oh, hai. I can haz sign-in?")

    Very cool idea.

    -Ashley
  • Ashley Pond V at Apr 8, 2008 at 4:42 am

    On Apr 7, 2008, at 8:04 PM, Ashley wrote:
    elsif $c->user_exists and $c->user->"generic_OpenID"
    Looking at this again, I think something like

    auto_role: "openid"

    could be go in the realm to add "openid" to a user's roles
    upon OpenID authentication. To get plain old-

    $c->check_roles("openid")
  • Aristotle Pagaltzis at Apr 8, 2008 at 10:10 pm

    * Ashley [2008-04-08 05:15]:
    "roles" for providers?
    I didn?t think of that. That sounds *very* cool.

    I wonder if this might possibly cause problems. One thing I?m not
    comfortable with, for a reason I can?t exactly pinpoint, is using
    the provider URI directly as a role. Maybe let the user configure
    a mapping from provider URIs to roles?

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Ashley Pond V at Apr 8, 2008 at 10:39 pm

    On Apr 8, 2008, at 2:11 PM, Aristotle Pagaltzis wrote:
    * Ashley [2008-04-08 05:15]:
    "roles" for providers?
    I didn?t think of that. That sounds *very* cool.

    I wonder if this might possibly cause problems. One thing I?m not
    comfortable with, for a reason I can?t exactly pinpoint, is using
    the provider URI directly as a role. Maybe let the user configure
    a mapping from provider URIs to roles?

    Sure. I'm kind of backed up this week with work but I'll try to
    get that brewing for release on the weekend... Not sure how to
    approach that this second anyway so a few days to steep will
    be good.

    -Ashley

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedApr 3, '08 at 5:38a
activeApr 8, '08 at 10:39p
posts11
users5
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase