Strategie di autorizzazione API REST

Ti preghiamo di amore per Dio non creare una classe SecurityUtils !

La tua classe diventerà 10 righe di codice spaghetti in pochi mesi! Dovresti avere un tipo Action (creare, leggere, aggiornare, distruggere, elencare, ecc.) Passato nel tuo metodo isUserAuthorized() , che diventerebbe rapidamente un'istruzione di switch di mille righe con logica sempre più complessa sarebbe difficile fare un test unitario. Non farlo.

Generalmente ciò che faccio, almeno in Ruby on Rails, è che ogni oggetto dominio è responsabile dei propri privilegi di accesso avendo una classe politica per ogni modello . Quindi, il controller richiede la classe della politica se l'utente corrente per la richiesta ha accesso alla risorsa o meno. Ecco un esempio in Ruby, dal momento che non ho mai implementato nulla di simile in Java, ma l'idea dovrebbe essere chiara:

class OrderPolicy

    class Scope < Struct.new(:user, :scope)

        def resolve

            # A user must be logged in to interact with this resource at all
            raise NotAuthorizedException unless user

            # Admin/moderator can see all orders
            if (user.admin? || user.moderator?)
                scope.all
            else
                # Only allow the user to see their own orders
                scope.where(orderer_id: user.id)
            end
        end
    end

    # Constructor, if you don't know Ruby
    def initialize(user, order)
        raise NotAuthorizedException unless user
        @user = user
        @order= order
    end

    # Whitelist what data can be manipulated by each type of user
    def valid_attributes
        if @user.admin?
            [:probably, :want, :to, :let, :admin, :update, :everything]
        elsif @user.moderator?
            [:fewer, :attributes, :but, :still, :most]
        else
            [:regualar, :user, :attributes]
        end
    end

    # Maybe restrict updatable attributes further
    def valid_update_attributes
    end

    # Who can create new orders
    def create?
        true # anyone, and they would have been authenticated already by #initialize
    end

    # Read operation
    def show?
        @user.admin? || @user.moderator? || owns_order
    end

    # Only superusers can update resources
    def update?
        @user.admin? || @user.moderator?
    end

    # Only admins can delete, because it's extremely destructive or whatever
    def destroy?
        @user.admin?
    end

    private

    # A user 'owns' an order if they were the person who submitted the order
    # E.g. superusers can access the order, but they didn't create it
    def owns_order
        @order.orderer_id == @user.id
    end
end

Anche se disponi di risorse nidificate complesse, alcune risorse devono "possedere" le risorse nidificate, quindi la logica di livello superiore è intrinsecamente negativa. Tuttavia, tali risorse nidificate necessitano delle proprie classi di politiche nel caso in cui possano essere aggiornate indipendentemente dalla risorsa "principale".

Nella mia applicazione, che è per il dipartimento della mia università, tutto ruota attorno all'oggetto Course . Non è un'applicazione User -centric. Tuttavia, User s sono iscritti in Course , quindi posso semplicemente assicurarmi che:

@course.users.include? current_user && (whatever_other_logic_I_need)

per qualsiasi risorsa che un particolare User deve modificare, poiché quasi tutte le risorse sono legate a Course . Questo viene fatto nella classe della politica nel metodo owns_whatever .

Non ho fatto molta architettura Java, ma sembra che tu possa creare un'interfaccia Policy , in cui le diverse risorse che devono essere autenticate devono implementare l'interfaccia. Quindi, disponi di tutti i metodi necessari che possono diventare complessi quanto è necessario che siano per oggetto dominio . L'importante è legare la logica al modello stesso, ma allo stesso tempo tenerla in una classe separata (principio di responsabilità singola (SRP)).

Le azioni del tuo controller potrebbero essere qualcosa di simile a:

public List<Order> index(OrderQuery query) {

    authorize(Order.class)
    // you should be auto-rescuing the NotAuthorizedException thrown by
    //the policy class at the controller level (or application level)

    // if the authorization didn't fail/rescue from exception, just render the resource
    List<Order> orders = db.search(query);
    return renderJSON(orders);
}

public Order show(int orderId) {

    authorize(Order.class)
    Order order = db.find(orderId);
    return renderJSON(order);
}

Una soluzione più comoda è usare le annotazioni per contrassegnare metodi che richiedono una qualche forma di autorizzazione. Ciò si distingue dal codice aziendale e può essere gestito da Spring Security o codice AOP personalizzato. Se si utilizzano queste annotazioni sui metodi aziendali anziché sugli endpoint, è possibile ottenere un'eccezione quando un utente non autorizzato tenta di chiamarli indipendentemente dal punto di ingresso.

Usa sicurezza basata sulle capacità.

Una capacità è un oggetto indimenticabile che funge da prova che si può eseguire una determinata azione. In questo caso:

• Trasforma ciascun ruolo (insieme di azioni consentite) in un'interfaccia.
• Le operazioni che richiedono l'autenticazione sono metodi sulle rispettive interfacce. Questi dovrebbero generare un'eccezione se il destinatario non è l'utente corrente della richiesta, se possibile.

Ciò rende impossibile provare a fare qualcosa che l'utente corrente non è autorizzato a fare.

In questo modo è impossibile