„Shibboleth Service Provider (SP) és Docker” változatai közötti eltérés
(→Load balance) |
|||
| (3 közbenső módosítás ugyanattól a szerkesztőtől nincs mutatva) | |||
| 4. sor: | 4. sor: | ||
= Apache 2.4 = | = Apache 2.4 = | ||
| + | Az alábbi példákban az SP és az alkalmazás konténer [https://en.wikipedia.org/wiki/TLS_termination_proxy SSL termination proxy] mögött helyezkedik el. Természetesen a VirtualHost átalakítható úgy, hogy SSL-t is ki tudjon szolgálni, ha erre van igény. | ||
== Proxy == | == Proxy == | ||
| 35. sor: | 36. sor: | ||
== Lazy session == | == Lazy session == | ||
| + | |||
| + | Az előző példához hasonlóan, a Shibboleth SP-vel védeni kívánt alkalmazást proxy-zuk egy másik futó konténerből, de csak a https://domain.com/secure útvonalat védjük. | ||
<VirtualHost *:80> | <VirtualHost *:80> | ||
| 65. sor: | 68. sor: | ||
= Shibboleth = | = Shibboleth = | ||
== Load balance == | == Load balance == | ||
| − | Terheléselosztó mögött a <code><Session></code> beállításnál érdemes a <code>consistentAddress="false"</code> értéket beállítani, ha tudjuk, hogy változó (LAN!) címekről érkeznek a felhasználók. | + | Terheléselosztó mögött a '''shibboleth2.xml'''-ben, a <code><Session></code> beállításnál érdemes a <code>consistentAddress="false"</code> értéket beállítani, ha tudjuk, hogy változó (LAN!) címekről érkeznek a felhasználók. |
A lap jelenlegi, 2018. május 24., 08:15-kori változata
Az alábbi lapon összefoglaljuk a legfontosabb lépéseket, melyek általános esetben elegendőek ahhoz, hogy működő Shibboleth SP-t állítsunk üzembe, Docker konténerben. Fontos, hogy rengeteg olyan igény lehet, amely további speciális beállítások meglétét teszik szükségessé, ezeket ezen a lapon nem részletezzük, ilyen irányú tájékozódáshoz legbiztosabb források:
Tartalomjegyzék
Apache 2.4
Az alábbi példákban az SP és az alkalmazás konténer SSL termination proxy mögött helyezkedik el. Természetesen a VirtualHost átalakítható úgy, hogy SSL-t is ki tudjon szolgálni, ha erre van igény.
Proxy
Ebben az esetben, a Shibboleth SP-vel védeni kívánt alkalmazást proxy-zuk egy másik futó konténerből.
<VirtualHost *:80>
ServerName https://domain:443
ServerAdmin admin@domain.com
UseCanonicalName On
ErrorLog /dev/stderr
CustomLog /dev/stdout combined
ProxyVia On
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /Shibboleth.sso !
ProxyPass / http://cel_kontener:8080/ retry=0 timeout=30
ProxyPassReverse / http://cel_kontener:8080/
<Location "/socket.io">
RewriteEngine On
RewriteCond %{QUERY_STRING} transport=websocket [NC]
RewriteRule /(.*) ws://cel_kontener:8080/socket.io/$1 [P,L]
ProxyPass http://cel_kontener:8080/socket.io retry=0 timeout=30
ProxyPassReverse http://cel_kontener:8080/socket.io
</Location>
<Proxy "*">
AuthType shibboleth
ShibRequestSetting requireSession 1
Require valid-user
</Proxy>
</VirtualHost>
Lazy session
Az előző példához hasonlóan, a Shibboleth SP-vel védeni kívánt alkalmazást proxy-zuk egy másik futó konténerből, de csak a https://domain.com/secure útvonalat védjük.
<VirtualHost *:80>
ServerName https://domain:443
ServerAdmin admin@domain.com
UseCanonicalName On
ErrorLog /dev/stderr
CustomLog /dev/stdout combined
ProxyVia On
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /Shibboleth.sso !
ProxyPass / http://cel_kontener:8080/ retry=0 timeout=30
ProxyPassReverse / http://cel_kontener:8080/
<Location "/secure">
AuthType Shibboleth
ShibRequestSetting requireSession true
ShibUseHeaders On
Require shibboleth
ProxyPass http://cel_kontener:8080/secure retry=0 timeout=30
ProxyPassReverse http://cel_kontener:8080/secure
</Location>
<Proxy "*">
AuthType shibboleth
ShibRequestSetting requireSession false
Require shibboleth
</Proxy>
</VirtualHost>
Shibboleth
Load balance
Terheléselosztó mögött a shibboleth2.xml-ben, a <Session> beállításnál érdemes a consistentAddress="false" értéket beállítani, ha tudjuk, hogy változó (LAN!) címekről érkeznek a felhasználók.
