Säkerhet

Lokal autentisering, auktorisering och användarhantering?

Mer
25 sep 2019 09:44 #77 av SA0CAD
Tack, men tyvärr är inte OS stödet för 4:an riktigt på plats ännu. I nödfall går det att använda en pi 3:a, men det är precis på gränsen att det går. Oklart hur pålitligt det skulle vara.

Be Logga in ansluta till konversationen.

Mer
24 sep 2019 23:20 #76 av sa0bxi
Andreas, jag kan låna ut en RPi4 som du kan köra cents på om du vill testa
raspberrytips.com/install-centos-raspberry-pi/

Be Logga in ansluta till konversationen.

Mer
20 sep 2019 12:22 #74 av SA0CAD
Ingen fara!

Jag har i efterhand insett att mitt förra inlägg i den här tråden är fullproppat med missförstånd, speciellt avseende certifikat och deras roll. Så se upp med det.

Det enda tråkiga med freeipa tycks vara att det är relativt resurskrävande samt mer eller mindre kräver fedora-baserat OS, vilket inte är ett problem i sig själv men innebär att raspberry pi:s i nuläget är olämpliga för att vara värd för freeipa (även om det går för experimenterande). (RPI 4 kommer att göra situationen lite bättre, it takt med att OSen mognar för plattformen). Då strömbudgeten i tornet på KTH kommer att vara begränsad till det alla mest nödvändiga (när batterier väl är på plats) så är det kanske inte det mest lämpliga stället för något mer energikrävande än typ en Rpi.

Sedan bör man fundera på vilken roll det här systemet är tänkt att spela, och i vilken situation. I en kris är det viktigare att det grundläggande fungerar (länkar, routing), och att det här systemet, säg, inte påverkar möjligheten att snabbt koppla på nya länkar eller modifiera gamla, medan det i "normala" fall är väldigt praktiskt med central användarhantering och tjänster kopplat till det (gitlab, radius, etc.).

Med det sagt, kan jag tänka mig att delta i studiecirkeln, med förbehållet att jag hittills har varit mer av en "dreamer" än en "doer".

Be Logga in ansluta till konversationen.

Mer
18 sep 2019 13:20 #73 av SA5BKE
Bra idéer, seg återkoppling från mig. :-)

Ja, visste vore det snyggt om varje klubb själv kunde ansvara för sina användare och ha sin egen instans. Det ena kanske inte utesluter det andra. Vi har sagt att vi ska försöka gå vidare med freeipa-spåret. Just nu kan den användas för inloggning i vår gitlab/mattermost. Tanken är att de som anmäler sig till studiecirkeln (i annan tråd) får ett konto i denna. Just nu finns det endast en freeipa-server. Jag skulle vilja ha en sekundär på annat ställe. Sedan titta på underdomäner också.

Du går gärna hjälpa till med detta!

Be Logga in ansluta till konversationen.

Mer
01 apr 2019 00:44 - 01 apr 2019 13:06 #26 av SA0CAD
Jag har precis börjat labba lite med FreeIPA, men jag har väl inte hunnit göra så där himla mycket. Men jag tror jag har hittat en *väldigt* intressant funktion som jag misstänker skulle kunna vara användbar, nämligen möjligheten att skapa subcertifikat för underzoner (med risk för att min terminologi brister): frasertweedale.github.io/blog-redhat/pos...-subordinate-ca.html

Det här borde kunna ge en bättre modell än följande alternativ:
- att ha fulla certifikat-replikor utplacerade hos varje organisation (osäkert, brister en är hela systemet knäckt för alla. För mycket priviligier)
- att enbart ha "read-only" (inget certifikat) replikor hos varje organisation (möjliggör access även i isolation, men omöjligt att lägga till nya användare lokalt. Även andra funktioner ej fungerande. Dessutom möjligt att från centralt håll låsa ute ute från egen utrustning. För lite privilegier).

Istället tänker jag mig att det finns en central freeipa för IDP.AMPRNET.SE, som sedan signerar undercertifikat för säg IDP.SK0BU.AMPRNET.SE som använder det för sin egen FreeIPA installation. På så sätt har man skapat en chain-of-trust som inte möjliggör för SK0BU att skapa användare för SK0??, medan man fortfarande kan välja att lita på en användare från SK0?? genom det centrala föräldercertifikatet.

Man kan tänka sig att även SSA har ett undercertifikat på samma sätt, för att identifiera personer med amatörradiocertifikat. Vilket ex. vis är användbart om man vill göra tillgänglig en radiostation remote med sändarmöjligheter, men bara för folk med certifikat. Eller bara för folk i SM0. Eller bara för betalande medlemar i SSA.

Jag tycker att det här är värt att undersöka vidare. Vad tror ni?

Edit: Ytterligare en länk med nyttig information: floblanc.wordpress.com/2017/12/05/demyst...omponent-in-freeipa/
Last edit: 01 apr 2019 13:06 by SA0CAD.

Be Logga in ansluta till konversationen.

Mer
27 mar 2019 13:30 #25 av sa0bxi
Kul att du är intresserad Andreas. Jag kan ordna en träff med exjobbaren om du vill, men vi kan det privat.

Be Logga in ansluta till konversationen.

Mer
27 mar 2019 13:15 #24 av SA0CAD
Ok, intressant från er båda.

Just FreeIPA har jag stött på när jag googlat runt lite, ibland i kombination med Keycloak. Jag inser också nu att man inte heller är begränsad till att ha enbart en identity provider, utan det är möjligt att använda flera, om man skulle vilja, både lokala och remote. Oavsett vilket, tycker jag att det känns som att flera av de projekten som diskuteras inte riktigt kan genomföras utan att man har en lösning för autensiering och auktorisering på plats, AMPRRoam är ett exempel som borde vara relativt enkel att få igång när det finns.

Jag är själv lite intresserad av att jobba på detta, men som alla andra gäller det att hitta tiden för det. Sen ska man inte sticka under stolen att mjukvarorna förmodligen inte är helt enkla att jobba med, speciellt inte då man bara har en grundläggande förståelse för de inblandade koncepten. Det är toppen att du också tittar på detta Björn, det ska bli intressant att höra vad exjobbet resulterar i!

Be Logga in ansluta till konversationen.

Mer
26 mar 2019 22:03 #22 av sa0bxi
hm, jag skrev ett inlägg och trodde att jag skickade det men kanske tryckte på fel knapp. Hursomhelst, Det finns ett par förslag som förhoppningsvis kommer i den exjobbsrapport som ännu inte kommit mig tillhanda.Det ena är helt enkelt spegling av hela användardatabasen som Eric säger, det andra bygger på att svar cachas. Cachen används i frånkopplad drift, med möjlighet för behörig administratör att vid behov. lägga till nya individer. Dessa varianter kommer dock förmodligen inte med i den pågående uppgraderingen av den ursprungliga implementeringen som ännu inte har flyttats över efter serverbyte och byte av certifikatleverantör, Exjobbaren har fått lov att lägga tid på att överklaga avslag på ansökan om förlängning av sitt uppehållstilstånd. Det är dessvärre brist på intresserade kompetenta friviliiga beredda att avsätta tid så det går inte jättefort. Om det finns några sådana som läser detta så hör av er!

Be Logga in ansluta till konversationen.

Mer
26 mar 2019 21:37 #21 av SA5BKE
Nja, det här är nog inte färdigdiskuterat, mycket bra frågor du kommer med. IDP är normalt sett en central tjänst, men tanken är nog att den ska kunna speglas ut (baserad på mysql) t.ex. till fickservern: www.amprnet.se/index.php/projekt/amprnet-fickserver . Men detta vet Björn BXI mer om.

Annars så jobbar nog de flesta med lokala konton på servrar, routrar och tjänster, men det är klart vi ska ha ett bra alternativ inom AMPRnet för att kunna erbjuda SSO som fungerar även lokalt / avskuret.

Ett alternativ som jag har labbat lite med är FreeIPA. Jag har faktiskt en installation igång på as1.idp.amprnet.se och det ska gå att att ha lokala replikor, men det har jag inte testat.

//Eric

Be Logga in ansluta till konversationen.

Mer
26 mar 2019 15:04 #15 av SA0CAD
Hej, första inlägget på detta forum för min del. Stort tack till alla inblandade!

Jag är nyfiken på hur diskusionerna har gått rörande behovet av användarhantering samt tillhörande tjänster kopplat till det. Det som i nuläget går att finna under projekt-tabben här på sidan handlar om den AMPR Identity Provider-tjänst som det skett vissa framsteg i, även om den inte verkar var funktionell för tillfället, idp.amprid.se returnerar en default Apache "it works!" sida.

Min frågeställning är egentligen rätt bred, men kort och gott undrar jag hur vi skulle önska att användarhantering ska gå till. Eftersom det finns som mål att AMPRNet ska vara funktionellt ner på /24(?) nivå, så tycks en decentraliserad lösning vara ett krav. Ovan nämnda IDP verkar i nuläget vara en centraliserad tjänst till sin natur, samtidigt som andra än enbart radioamatörer kommer behöva hanteras. Ett alternativ är att låta varje organisation sköta användarhantering lokalt, så att tjänster som AMPRoam osv. kan fungera även i isolerade öar. Dock är då frågan hur man hanterar användare som besöker eller ska ha behörighet att hantera tjänster eller utrustning på andra platser än "hemmabasen". I fallet där platserna har en fungerande anslutning till varandra lär det vara möjligt att vidarebefodra förfrågan till hemmabasen, likt eduroam fungerar, men i fallet då en sådan anslutning ej fungerar vet jag inte hur det skulle gå till.

Jag misstänker att detta redan har diskuterats, men nu när vi har ett så fint forum så tycker jag att det är dags att fylla det med tankar och idéer som går att finna igen. :)

Be Logga in ansluta till konversationen.

Powered by Kunena Forum