You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When user starts enrollment we must give it JWT session token/cookie that marks this session as enrollment session for callsign X
Once user has delivered their auth code to the RASENMAEHER superuser and superuser has approved it their view changes to user instructions to download and install the device certificate. The device cert is loaded as binary from url /prefix/$callsign/client.pfx this URL must check the enrollment JWT matches the callsign.
RASENMAEHER api must store the users cert,key and pfx somewhere on local volume (sorted into subdirs by callsign, callsigns annot be re-used anyway) for future needs (like passing product [like TAK] integration APIs when requesting end-user instructions)
Below the installation instructions and link to pfx is a button to "check certicate" which connects to the mtls URL (browser will now ask user to choose the cert) and if the echo endpoint at mtls responds then we update both the JWT and local storage for the RASENMAEHER web ui to note that enrollment is complete after which the UI will always use the mtls url for all API calls.
sequenceDiagram
participant FE as Frontend (used by Eeli)
participant RM as RASENMAEHER
participant TP as Tilauspalvelu
TP ->> RM: Create code (tp signed JWT) for anon admin
RM ->> TP:
TP ->> FE: Deliver code somehow
FE ->> RM: Exchange code for session anon_admin JWT
RM ->> FE:
FE ->> RM: Use anon_admin JWT to create admin user with callsign
RM ->> FE: Code that can be exchanged for sessiont JWT
FE ->> RM: Exchange code for session callsign JWT
RM ->> FE:
FE ->> RM: Use JWT to fetch mTLS PFX
RM ->> FE:
FE ->> RM: Use mTLS auth to create new enrollments, pools etc
Loading
The "first user admin" login token could in theory be delivered to another person or another device if the true first admin (that got a login token from TILAUSPALVELU) wishes to do so.
sequenceDiagram
actor E as Eeli
participant RM as RASENMAEHER+Frontend
actor J as Janne
E ->> RM: Create new pool (mTLS auth)
RM ->> E: Invitecode
E ->> J: Deliver invitecode
J ->> RM: Use invitecode to start enrollment
RM ->> J: Approvecode and JWT for checking status
J ->> E: Deliver approvecode
E ->> RM: Use code to approve enrollment
J ->> RM: Use JWT to check if enrollment is ok
RM ->> J:
J ->> RM: Use JWT to get PFX for mTLS certs
RM ->> J:
J ->> RM: Use mTLS to get client configs, instructions etc
When user starts enrollment we must give it JWT session token/cookie that marks this session as enrollment session for callsign X
Once user has delivered their auth code to the RASENMAEHER superuser and superuser has approved it their view changes to user instructions to download and install the device certificate. The device cert is loaded as binary from url /prefix/$callsign/client.pfx this URL must check the enrollment JWT matches the callsign.
RASENMAEHER api must store the users cert,key and pfx somewhere on local volume (sorted into subdirs by callsign, callsigns annot be re-used anyway) for future needs (like passing product [like TAK] integration APIs when requesting end-user instructions)
Below the installation instructions and link to pfx is a button to "check certicate" which connects to the mtls URL (browser will now ask user to choose the cert) and if the echo endpoint at mtls responds then we update both the JWT and local storage for the RASENMAEHER web ui to note that enrollment is complete after which the UI will always use the mtls url for all API calls.
sequenceDiagram participant FE as Frontend (used by Eeli) participant RM as RASENMAEHER participant TP as Tilauspalvelu TP ->> RM: Create code (tp signed JWT) for anon admin RM ->> TP: TP ->> FE: Deliver code somehow FE ->> RM: Exchange code for session anon_admin JWT RM ->> FE: FE ->> RM: Use anon_admin JWT to create admin user with callsign RM ->> FE: Code that can be exchanged for sessiont JWT FE ->> RM: Exchange code for session callsign JWT RM ->> FE: FE ->> RM: Use JWT to fetch mTLS PFX RM ->> FE: FE ->> RM: Use mTLS auth to create new enrollments, pools etcThe "first user admin" login token could in theory be delivered to another person or another device if the true first admin (that got a login token from TILAUSPALVELU) wishes to do so.
sequenceDiagram actor E as Eeli participant RM as RASENMAEHER+Frontend actor J as Janne E ->> RM: Create new pool (mTLS auth) RM ->> E: Invitecode E ->> J: Deliver invitecode J ->> RM: Use invitecode to start enrollment RM ->> J: Approvecode and JWT for checking status J ->> E: Deliver approvecode E ->> RM: Use code to approve enrollment J ->> RM: Use JWT to check if enrollment is ok RM ->> J: J ->> RM: Use JWT to get PFX for mTLS certs RM ->> J: J ->> RM: Use mTLS to get client configs, instructions etc