Ich gebe zu, ich habe es lang vor mir her geschoben:
Neben all der schönen REST-fähigen Implementierung, ist Sicherheit ein Bereich, der bisher ein wenig zu kurz kam. Zwar habe ich schon eine schöne Möglichkeit gefunden, wie man mit YUI eine Anmeldung über HTTP AUTH hin bekommt, aber letztendlich fehlt(e) bisher die komplette Serverseite.
Ich habe jetzt einiger Zeit gesucht und bin zu dem Ergebnis gekommen, dass mir der Java Application Server (sei es Tomcat, Glassfish o.a.) bereits mehrere JAAS basierte Module zur Verfügung stellt.
Diese Entscheidung traf ich (da es hierbei sicherlich auch Einschränkungen einzugehen gilt) u.a. nach dem Lesen dieses Artikels.
Darin wird einem abgeraten, eine Logion/Session Verwaltung in Eigenregie zu erstellen, da hierdurch teilweise ein Sicherheitsrisiko eingegangen wird.
Nach weitere Suche kam ich zu einem interessanten Artikel von Shing Wai Chan, in dem er die Einrichtung eines JDBCRealm auf einem GlassFish Server beschreibt. Bis auf das die Standard digest-Algorithmen auf den verschiedenen Application Servern unterschiedlich sind, sollte dies unter den verschiedenen Systemen lauffähig sein.
Aufgrund der Übersichtlichkeit und da ich ungern Systeme in meinen Datentabellen rumfuhrwerken lasse, habe ich mir für die entsprechend benötigten Tabellen 2 Views angelegt:
SELECT u.email AS userid, u.password
FROM Users u CREATE ALGORITHM = TEMPTABLE VIEW grouptable AS
SELECT u.email AS userid, g.name
FROM Groups g, Users u, UsersGroups us
WHERE us.user_id = u.user_id
AND g.group_id = us.group_id
Damit kann ich weiterhin sicher sein, dass der Server auch tatsächlich auf die Standard-Variablen zugreifen kann. Natürlich bin ich damit den Nachteil eingegangen, dass ein Benutzer hier nur in einer Gruppe sein kann.
Ich denke aber, dass dies zu verkraften ist, da es sich hierbei nur um den Login handelt und hierbei eigentlich nur interessant ist, ob der Benutzer als Admin oder als User angemeldet wird.
Als Standardgruppen sind in der Datenbank admins und users gesetzt.
So habe ich in meiner config Datei (sun-web.xml) folgende Zeilen eingefügt:
<role-name>cotodo-admin-login</role-name>
<principal-name class-name="Users">admin</principal-name>
<group-name>admins</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>cotodo-user-login</role-name>
<principal-name class-name="Users">admin</principal-name>
<group-name>users</group-name>
</security-role-mapping>
Also Session Methode werde ich mich dann wohl für eine Cookie basierte Session entscheiden, weil eine URL-encodierte Session die schönen REST-URIs verschandeln würde und dadurch auch den Austausch mit YUI erschweren mag.
Meine beiden letzten Punkte auf der Agenda (die ich diese Jahr noch durchbekommen will (!!!), sind folgende:
- Wie gehe ich sicher dass ein User umgeleitet wird, wenn er eine ungültige Session hat und sich einen XML-Resource Stream besorgt? (letztendlich wird es da sicherlich entsprechende Methoden geben, welche vor allen anderen Aufrufen prüfen können, ob Autorisation und Authentisierung korrekt sind.
- HTTPS. Es war erstaunlich einfach, dem Server klar zu machen, dass ich gerne HTTPS benutzen möchte (einfach andere URL :-)) . Allerdings sollte man nun sicher sein dass:
- a) Alle Anfragen auf HTTP geblockt werden (oder noch besser: auf eine Loginseite umgeleitet werden)
- b) Sicher gestellt wird, dass sich ein User nur über eine SSL Verbindung anmelden kann (sicherlich auch durch eine Weiterleitung möglich)
Blogged with Flock
Comments (1)
Warum brauchst Du Cookies? HTTP Basic Auth wird vom Browser direkt unterstützt und passt zur Server-Seite ... für Atom brauchst Du es sowieso, da Cookies dafür praktisch nicht nutzbar sind.
Zu SSL: In aller Regel - so auch in unserer Infrastruktur - überlässt man SSL einem vorgeschalteten Apache. (Eigentlich kann der sogar die Authentifizierung übernehmen ... aber das ist Geschmackssache).
Posted by Stefan Tilkov | December 17, 2007 11:07 AM
Posted on December 17, 2007 11:07