Der REST-Server ist komplett zustandslos. Je nach Konfiguration werden bei jedem Aufruf Authentifizierungsdaten verlangt.
Aktuell wird nur HTTP Basis-Authentifizierung unterstützt. Bei Verwendung über SSL sollte dies kein Sicherheitsrisiko darstellen.
(Header-Attribut: Authorization: Basic <Benutzer:Passwort in base64>, Bsp für den Benutzer "test" mit Pwd "test": Authorization: basic dGVzdDp0ZXN0).
Bei erfolgreicher Authentifizierung wird der Aufruf im Kontext des angegebenen Benutzers ausgeführt, es gelten somit immer die Berechtigungen dieses Benutzers.
Verwendung von Token
Alternativ kann token-basiert gearbeitet werden. Dies erlaubt ein clientseitiges Arbeiten, ohne dass ein Passwort gespeichert werden muss.
Die Gültigkeitsdauer der Token kann im REST-Server konfiguriert werden.
Über die Authentifizierungsmethode ../SecUserMethods/method/Authenticate kann ein Token angefordert werden, das anstatt Benutzer/Pwd in den folgenden Aufrufen im Header übergeben werden kann (Header-Attribut: Authorization: Token <Token>).
Validierung von Token
Der REST-Server kann dazu verwendet werden, Single Sign-on Funktionalität zu realisieren. Dazu steht eine Funktion zur Verfügung um ein Token verifizieren zu lassen. Die Methode dazu heisst ../SecUserMethods/method/ValidateToken.
Bei Authenticate und ValidateToken kann ein optionaler Parameter ClientID mitgegeben werden, mit dem das Token zusätzlich auf seine Herkunft überprüft werden kann. Damit können Replay-Attacken verhindert werden.
Die Client-ID ist typischerweise die IP des Clients oder besser seine Session-ID.
Zusammenfassung der Authentifizierungs- und Verwaltungsmethoden:
Basis-Url für alle Methoden ist ../SecUserMethods/method.
| Operation | Endpunkt/Name | Parameter | Return | Info |
|---|---|---|---|---|
| Authentifizierung | Authenticate | Name | Token | GET,PUT,POST, ohne Auth-Daten, Return bei Erfolg Token, sonst Fehlercode 401 |
| Password | ||||
| ClientID | Optional, IP des Clients, Session-ID | |||
| Validierung | ValidateToken | Token | true/false | GET,PUT,POST |
| ClientID | Optional, IP des Clients, Session-ID | |||
| Passwort ändern | ChangePwd | Name | - | PUT/POST |
| Password |
Beispiele:
http://178.250.26.145:8084/rest2/SecUserMethods/method/Authenticate?name=me&password=mypwd&clientid=123.34.56.78
http://178.250.26.145:8084/rest2/SecUserMethods/method/ValidateToken?token=1234?clientid=123.34.56.78
Die Authentifizierung sollte über PUT oder POST aufgerufen werden, damit das Passwort nicht in der URL mitgegeben werden muss (URLs werden oft in Serverlogs gespeichert, ein Passwort in Klartext sollte da nicht auftauchen!)
Cross Origin Resource Sharing (CORS)
Um den Zugriff auf den Server für einen Webbrowser-Client (Chrome, Firefox, etc.) freizugeben, wird das CORS-Prinzip eingesetzt. Die serverseitigen Einstellungen werden im Server-Ini vorgenommen (/wiki/spaces/TD/pages/15597672). Kurzgefasst evaluiert CORS ob der Webbrowser-Client (welcher eine andere Herkunft besitzt) Zugriff auf den Server hat. Hierbei gibt es zwei Arten von "Use Cases":
- Simple Request: Wird bei den HTTP GET, HEAD und POST Methoden angewendet. Bei der POST-Methode sind nur folgende Content-Types erlaubt: text/plain, application/x-www-form-urlencoded und multipart/form-data.
- Preflighted requests: Kann der "Simple Request" nicht angewendet werden, wird zuerst ein HTTP OPTIONS request abgesetzt.
Dieses Prinzip wird nur von Webbrowser eingesetzt und muss somit nur freigeschaltet werden, wenn der Request direkt vom Browser getätigt wird (zum Beispiel beim Einsatz von Angular).