# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 34
# self = https://watcher.sour.is/conv/gfpkedq
Speaking of SSO and a draft blog post I'm writing that I _think_ I'll call Protecting Internal Web Resources (_comments, feedback welcome before I publish π_) -- I've been thinking for a while now about building a new project based around Indie Auth that provides a full solution to managing a set of users that you could use in place of the more traditional approach of LDAP or Active Directory (_shudder π_). The use-case I have in mind is to (for example) have auth.example.com that runs this software, lets me manage users, users can manage their credentials, information, etc. Then other software like Gitea, Authelia, or basically anything you want _could_ use it as an "Authentication backend" / "Identity Provider".
Thoughts? π€
Btw, did you know that most (_all?_) Yarn.social pods are actually* already working IndieAuth Identity providers and you can auth against your own pod to anything that can use Indie Auth? π
_*
Speaking of SSO and a draft blog post I'm writing that I _think_ I'll call Protecting Internal Web Resources (_comments, feedback welcome before I publish π_) -- I've been thinking for a while now about building a new project based around Indie Auth that provides a full solution to managing a set of users that you could use in place of the more traditional approach of LDAP or Active Directory (_shudder π_). The use-case I have in mind is to (for example) have auth.example.com that runs this software, lets me manage users, users can manage their credentials, information, etc. Then other software like Gitea, Authelia, or basically anything you want _could_ use it as an "Authentication backend" / "Identity Provider".
Thoughts? π€
Btw, did you know that most (_all?_) Yarn.social pods are actually* already working IndieAuth Identity providers and you can auth against your own pod to anything that can use Indie Auth? π
*_
@prologic I did know that about IndieAuth and yarn!
I'd love to be able to use IndieAuth to manage authentication for all my web apps. That'd be close to ideal for me I think.
@abucci I _think_ it would solve a lot of problems for me too π Maybe you could help think of a minimal feature set of "must haves" and "nice to haves" and "optional features"? That would help understand my use-case and yours and maybe anyone else _that_ might need something like this (I suspect more than just you and i)
@abucci I _think_ it would solve a lot of problems for me too π Maybe you could help think of a minimal feature set of "must haves" and "nice to haves" and "optional features"? That would help understand my use-case and yours and maybe anyone else _that_ might need something like this (I suspect more than just you and i)
@prologic Sure, off the top of my head:
User management:
- Add/edit/delete users
- Monitor user actions (at least login)
In a RBAC (Role Based Access Control) setting:
Role management:
- Add/edit/delete roles
- Monitor role usage by user
Service management:
- Add/edit/delete services
- Monitor service usage (at least logins)
Policy management:
- Add a service to a role
- Grant a role access to a service
- Revoke a role's access to a service
- Revoke a user's access to a service
If you haven't seen it before, Casbin is pretty great for structuring a lot of this policy stuff, and it can handle other models like ACL if you don't like RBAC. I *think* it was even written in golang originally!
@abucci As a fun fact, Sandstorm is neither RBAC or ACL, it uses object capabilities, which is a superior but niche model also seen in Google's Fuchsia and a very limited number of random things since the 1980's.
@prologic I really like Active Directory still. Mostly for Group Policy though, which only works on Windows.
@ocdtrekkie I wonder how far you could get with ABAC (Attribute Based Access Control), which Casbin supports directly. Casbin has a meta-model that can probably express capability based access control. I haven't tried that so I can't say for sure. Anyway, since we're spitballing requirements maybe we should consider CBAC too.
@ocdtrekkie Well you would Haha π€£ Since that's the "space" in which you work right? π€ But yes pretty useless outside of Windows really π
@ocdtrekkie Well you would Haha π€£ Since that's the "space" in which you work right? π€ But yes pretty useless outside of Windows really π
@abucci What I've learned in production is the apps need to be built or heavily modified to truly support object capabilities. We've packaged numerous apps for Sandstorm, but the best experience is still apps written to work in that environment, even if they aren't as feature-heavy.
@ocdtrekkie And that's half the other problem I have too:
> but the best experience is still apps written to work in that environment, even if they arenβt as feature-heavy
This increases frictions for developers writing apps for or packaging or modifying existing apps for Sandstorm.
@ocdtrekkie And that's half the other problem I have too:
> but the best experience is still apps written to work in that environment, even if they arenβt as feature-heavy
This increases frictions for developers writing apps for or packaging or modifying existing apps for Sandstorm.
@abucci Hnnnn kind of wondering whether your list of requirements are a bit over-scoped? Services? How would that play with something that is essentially OAuth2 flows (IndieAuth)? Also are Roles basically Groups in your head? π€
@abucci Hnnnn kind of wondering whether your list of requirements are a bit over-scoped? Services? How would that play with something that is essentially OAuth2 flows (IndieAuth)? Also are Roles basically Groups in your head? π€
@prologic True, though it becomes less of a problem once people realize writing apps with traditional security models is bad and everyone does it our way. ;)
The challenge with changing the world is overcoming momentum.
@ocdtrekkie You _may_ be right in that Capability based Security is the "better" way of securing applications and data access, sure, but we do probably need to innovate here, right now I _feel_ like I'm at a point where my understanding of and experience with CAS (if that's a valid acronym for this?) is limited and whilst I will continue to think about it, I'm unlikely to adopt the Sandstorm model as-is.
@ocdtrekkie You _may_ be right in that Capability based Security is the "better" way of securing applications and data access, sure, but we do probably need to innovate here, right now I _feel_ like I'm at a point where my understanding of and experience with CAS (if that's a valid acronym for this?) is limited and whilst I will continue to think about it, I'm unlikely to adopt the Sandstorm model as-is.
@prologic RBAC may be overkill, I dunno.
- Role: Webmail User
- Service: Roundcube
- User: abucci
- Policy: Webmail User has access to Roundcube.
^ It can't be overscoped, because you need to specify that kind of stuff one way or another; otherwise you're not really doing authorization. RBAC is just one way of organizing this information.
Giving user abucci the Webmail User Role allows abucci to start using Roundcube. You'd have to store the credentials and login flow and so on for user abucci of course.
@prologic The official lingo is ocap for object capabilities. And FWIW that is still IMHO just a need for better implementation by Sandstorm: Capabilities done right actually cause a lot less friction than ACLs!
@abucci Oh wait a damn minute π
I was only talking about the "Authentication" / "Identity" part here. The RBAC / Roles you're describing here are handled quite nicely by Authelia -- What I was thinking of was to write an Authentication backend for Authelia (as an alternative to LDAP or the YAML users file). That's all π€£ Let Authelia handle all the RBAC and ACLs.
@abucci Oh wait a damn minute π
I was only talking about the "Authentication" / "Identity" part here. The RBAC / Roles you're describing here are handled quite nicely by Authelia -- What I was thinking of was to write an Authentication backend for Authelia (as an alternative to LDAP or the YAML users file). That's all π€£ Let Authelia handle all the RBAC and ACLs.
@prologic ohhhhhhhhhhhhhhhhhhhhhhhhhhhh.
Sorry!
Then yes, everything I wrote is overkill. Scratch that!
@prologic Oh well shit that ought to be pretty straightforward (I'm saying as a person who's never used Authelia)? Yeah I have no sense for how it works or what it'd take to write an authentication backend for it so I'm not sure what to say requirements-wise. Will have to play with it first.
@abucci Although that being said, I _think_ your wish-list is definitely a v2 of something like what I described + Authelia and maybe a few extra tidbits? π€
@abucci Although that being said, I _think_ your wish-list is definitely a v2 of something like what I described + Authelia and maybe a few extra tidbits? π€
@prologic yeah, a full-on user management system that allows you to inspect who can do what and add/revoke people and services and whatnot would be very handy. But since Authelia sounds like it does RBAC already the immediate need for integrating with IndieAuth is the authentication component, like you said. That prioritization makes sense to me.
@abucci Yup π Get that working well, then _one day_ (maybe?) combine the two into a single thing? π€
@abucci Yup π Get that working well, then _one day_ (maybe?) combine the two into a single thing? π€