Spacc BBS Spacc BBS
    • Categorie
    • Recenti
    • Tag
    • Popolare
    • Mondo
    • Utenti
    • Gruppi
    • Registrati
    • Accedi
    La nuova BBS Γ¨ in fase Alpha. I post precedenti al 22 luglio 2024 potrebbero non essere trasferibili, ma rimarranno disponibili per la lettura su /old/.

    @julian diving into the hard problems of building for the Fediverse at #Fedicon, starting with hilariously talking about how those hard problems look like to average users πŸ˜…

    Pianificato Fissato Bloccato Spostato Uncategorized
    fedicon
    99 Post 13 Autori 218 Visualizzazioni
    Caricamento altri post
    • Da Vecchi a Nuovi
    • Da Nuovi a Vecchi
    • PiΓΉ Voti
    Rispondi
    • Topic risposta
    Effettua l'accesso per rispondere
    Questa discussione Γ¨ stata eliminata. Solo gli utenti con diritti di gestione possono vederla.
    • thisismissem@hachyderm.ioT Questo utente Γ¨ esterno a questo forum
      thisismissem@hachyderm.io @thisismissem@hachyderm.io
      ultima modifica di

      @evan @julian @naturzukunft @aaronpk can keycloak support Client ID Metadata Documents? Currently not to my knowledge, but it's a lot easier to support because it's effectively the same process as dynamic client registration because the document payload is the same.

      1 Risposta Ultima Risposta Rispondi Cita 0
      • thisismissem@hachyderm.ioT Questo utente Γ¨ esterno a questo forum
        thisismissem@hachyderm.io @evan@cosocial.ca
        ultima modifica di

        @evan @julian @naturzukunft OAuth isn't AP-centric, and never will be, that's probably your first error. Most OAuth clients will never need to be AP Actors.

        Discovery isn't "complex", it's literally a HTTP request to a well known endpoint for a JSON document.

        You can't do OAuth whilst ignoring all the OAuth standards.

        evan@cosocial.caE 1 Risposta Ultima Risposta Rispondi Cita 0
        • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
          evan@cosocial.ca @evan@cosocial.ca
          ultima modifica di

          @julian @naturzukunft @thisismissem

          A cursory search shows that it's possible to implement a new ClientLookupProvider with KeyCloak extension SPIs. It sounds like a fun project to do; I don't get a lot of chance to write Java code.

          1 Risposta Ultima Risposta Rispondi Cita 0
          • naturzukunft@mastodon.socialN Questo utente Γ¨ esterno a questo forum
            naturzukunft@mastodon.social @evan@cosocial.ca
            ultima modifica di

            @evan @julian @thisismissem
            "I have not looked closely enough at keycloak to see if there's a way to build a plugin or to have configurable executable code to do that."

            I don't plan to adapt a standard OAuth2 server to support ActivityPub. I think that if that's necessary, something is fundamentally wrong.

            evan@cosocial.caE 1 Risposta Ultima Risposta Rispondi Cita 0
            • naturzukunft@mastodon.socialN Questo utente Γ¨ esterno a questo forum
              naturzukunft@mastodon.social
              ultima modifica di

              @julian @thisismissem https://socialhub.activitypub.rocks/t/fep-d8c2-oauth-2-0-profile-for-the-activitypub-api/3575/2?u=naturzukunft

              1 Risposta Ultima Risposta Rispondi Cita 0
              • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                evan@cosocial.ca @thisismissem@hachyderm.io
                ultima modifica di

                @thisismissem @julian @naturzukunft the point of discovery is to find the important endpoints and parameters for the flows. Many implementers who are concentrating on a single API skip discovery because the resource provider has already defined the specific flow. Alternatively, many API providers allow client registration out of band. It is absolutely 100% OK to do OAuth without using features like discovery and dynamic client registration.

                benpate@mastodon.socialB 1 Risposta Ultima Risposta Rispondi Cita 0
                • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                  evan@cosocial.ca @naturzukunft@mastodon.social
                  ultima modifica di

                  @naturzukunft @julian @thisismissem that's fine; you should do whatever it is you want.

                  evan@cosocial.caE 1 Risposta Ultima Risposta Rispondi Cita 0
                  • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                    evan@cosocial.ca @evan@cosocial.ca
                    ultima modifica di

                    @naturzukunft @julian @thisismissem oh, are you going to use Keycloak's built in user database, or are you going to use an adapter to fetch user data from your own database?

                    evan@cosocial.caE naturzukunft@mastodon.socialN 3 Risposte Ultima Risposta Rispondi Cita 0
                    • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                      evan@cosocial.ca @evan@cosocial.ca
                      ultima modifica di

                      @naturzukunft @julian @thisismissem oh, it looks like Authentik has ways to do client metadata lookup with a Webhook. Nice!

                      1 Risposta Ultima Risposta Rispondi Cita 0
                      • naturzukunft@mastodon.socialN Questo utente Γ¨ esterno a questo forum
                        naturzukunft@mastodon.social @evan@cosocial.ca
                        ultima modifica di

                        @evan @julian @thisismissem which user data to do what ?

                        evan@cosocial.caE 1 Risposta Ultima Risposta Rispondi Cita 0
                        • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                          evan@cosocial.ca @naturzukunft@mastodon.social
                          ultima modifica di

                          @naturzukunft @julian @thisismissem oh, sorry. By default, KeyCloak stores all the user data (name, avatar, description, so on) in its own internal PostgreSQL database, and you get an API to ask about and manage users.

                          The alternative is to add a custom UserStorageProvider class to access your own user storage and map your data to KeyCloak's schema. Applications that already have a user database often do this.

                          thisismissem@hachyderm.ioT 1 Risposta Ultima Risposta Rispondi Cita 0
                          • thisismissem@hachyderm.ioT Questo utente Γ¨ esterno a questo forum
                            thisismissem@hachyderm.io @evan@cosocial.ca
                            ultima modifica di

                            @evan @naturzukunft @julian in the wild it's very uncommon to replace Keycloak's user database with something else; most commonly user migrations are performed, having been involved in several such projects.

                            evan@cosocial.caE 1 Risposta Ultima Risposta Rispondi Cita 0
                            • naturzukunft@mastodon.socialN Questo utente Γ¨ esterno a questo forum
                              naturzukunft@mastodon.social @evan@cosocial.ca
                              ultima modifica di

                              @evan @julian @thisismissem There is a mapping in the resource server between PreferredUsername and an actor. This is a hack; I had to extend it because Mastodon uses the username as a unique identifier. Without Mastodon support, it would be a mapping between IssuerUserId and Actor. The data for the mapping comes from the JWT token.

                              But that's beside the point.

                              evan@cosocial.caE thisismissem@hachyderm.ioT 2 Risposte Ultima Risposta Rispondi Cita 0
                              • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                                evan@cosocial.ca @thisismissem@hachyderm.io
                                ultima modifica di

                                @thisismissem @julian great, so that's what
                                @naturzukunft can do.

                                1 Risposta Ultima Risposta Rispondi Cita 0
                                • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                                  evan@cosocial.ca @naturzukunft@mastodon.social
                                  ultima modifica di

                                  @naturzukunft @julian @thisismissem I think your point was that any configuration that requires adding plugins or adapters for KeyCloak is a bad architecture, and you're committed to using KC entirely off-the-shelf.

                                  thisismissem@hachyderm.ioT 1 Risposta Ultima Risposta Rispondi Cita 0
                                  • thisismissem@hachyderm.ioT Questo utente Γ¨ esterno a questo forum
                                    thisismissem@hachyderm.io @naturzukunft@mastodon.social
                                    ultima modifica di

                                    @naturzukunft @evan @julian we have a userinfo endpoint now in mastodon that gives you a unique subject (sub) claim: https://docs.joinmastodon.org/methods/oauth/#userinfo

                                    This is all discoverable via standards that exist in OAuth (with a touch of OIDC language)

                                    evan@cosocial.caE 1 Risposta Ultima Risposta Rispondi Cita 0
                                    • thisismissem@hachyderm.ioT Questo utente Γ¨ esterno a questo forum
                                      thisismissem@hachyderm.io @evan@cosocial.ca
                                      ultima modifica di

                                      @evan @naturzukunft @julian as Client ID Metadata Documents move through the standards process, I would assume keycloak will adopt them and Client ID Prefixes.

                                      thisismissem@hachyderm.ioT evan@cosocial.caE 2 Risposte Ultima Risposta Rispondi Cita 0
                                      • thisismissem@hachyderm.ioT Questo utente Γ¨ esterno a questo forum
                                        thisismissem@hachyderm.io @thisismissem@hachyderm.io
                                        ultima modifica di

                                        @evan @naturzukunft @julian but keycloak being able to understand wtf a json-ld document of type Service or Application is? Incredibly unlikely, especially when the contents within isn't even remotely aligned with the IANA registry for Dynamic Client Registration Metadata values.

                                        evan@cosocial.caE 1 Risposta Ultima Risposta Rispondi Cita 0
                                        • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                                          evan@cosocial.ca @thisismissem@hachyderm.io
                                          ultima modifica di

                                          @thisismissem @naturzukunft @julian but they don't work right now, out of the box? I think that doesn't meet his requirements then.

                                          thisismissem@hachyderm.ioT 1 Risposta Ultima Risposta Rispondi Cita 0
                                          • evan@cosocial.caE Questo utente Γ¨ esterno a questo forum
                                            evan@cosocial.ca @thisismissem@hachyderm.io
                                            ultima modifica di

                                            @thisismissem @julian sorry, I don't know what you're talking about.

                                            KeyCloak has an extension mechanism and you can use it to retrieve a Client object from somewhere besides the built-in database. But someone needs to write that plugin. @naturzukunft said it wasn't acceptable for him to use any kind of extension or plugin.

                                            https://cosocial.ca/@evan/114972162312054007

                                            1 Risposta Ultima Risposta Rispondi Cita 0
                                            • Primo post
                                              Ultimo post