Verstehen von Ansprüchen

Question

Ich versuche, mich mit OpenId Connect, OAuth2.0, Sicherheitstokendienst und Claims vertraut zu machen. Stellen Sie sich ein Szenario mit einer großen Website mit vielen Bereichen und unterschiedlicher Funktionalität vor, z. Kunde, Auftrag, Lieferant, Lieferung, Rückkehr etc. Meine Frage ist das - würde ich Ansprüche auf dem Token-Server wie CanCreateCustomer, CanReadCustomer, CanUpdateCustomer, CanDeleteCustomer usw., d. H. Effektiv CRUD-Ansprüche für jeden Hauptbereich/Business-Objekt erstellen? Dies würde zu vielen zehn aber wahrscheinlichen hunderten von Ansprüchen führen. Oder kommt mein Verständnis zu kurz?

Answer 1

Ich denke, Ihr Verständnis ist weitgehend richtig. Wenn ich jedoch verstehe, was Sie richtig beschreiben, scheint es eher ein Autorisierungs- (OAuth) als ein Authentifizierung (OIDC) -Problem zu sein, und Sie können sich daher anschauen, wie andere OAuth-Ressourcenanbieter ihre Bereiche definieren (nicht Ansprüche). zum Beispiel GitHub oder Slack.

Answer 2

Ihr Verständnis ist richtig, aber Sie haben viel mehr Flexibilität in OAuth2.0 Tive (Ansprüche)

Diese Bereiche können zB in irgendeiner Weise konfiguriert werden, in Ihrem Fall statt der Schaffung einzelner Bereiche für jede CRUD Operation für jeden Hauptbereich, Sie Gruppenbereiche wie

customer.read_write 
order.read_write 

usw. erstellen können, können Sie auch eine Ebene höher, gehen durch Funktionalität Ebene Bereiche zu schaffen, wie

webportal.full_access 
adminportal.full_access 

dann in der Anwendung, nach der Authentifizierung kann die Genehmigung wie

ValidScopesIn({Scopes.WEBPORTAL_FULL_ACCESS, Scopes.CUSTOMER_READ_WRITE}) 
public void createCustomer(Customer customer) { 
// your creation logic 
} 

Answer 3

getan würde ich empfehlen, dass „Bereiche“, wie URIs konfiguriert werden, so dass Kollisionen nicht auftreten.

Als example.

-jim