Federation, access security.

Not long ago I secured the external connection to Indigo server using Active Directory Federation Services + Web Application Proxy, that's a long name; anyway, I have no idea how exactly REST APIs communicate, if they're secure or not but what I do know is that no cert = cleartext, plus Federation Services, let's us use our existing accounts instead of Indigo's single account approach--for that authentication had to be turned off and shortly thereafter Indigo Touch wouldn't connect anymore unless a unencrypted passwordless (since it has been removed for Federation) port is punched through the firewall or using either Always-On or On-Demand IKEv2, that introduces new issues on its own though, Always-On IKEv2 truly is ALWAYS-ON, if it's switched off manually, all data transfer ceases, it doesn't play nice with multicast traffic either--no Apple TV remote, Harmony is also slow because it's routed way longer. On-Demand IKEv2 not always dials or brings up the tunnel quick enough.

It gets crazier though, less than a month ago I found an Indigo client for Android--and it works! ...with some issues here and there and sort of ugly UI, but it's customizable and it's Android; can't expect too much.

Details done, my question is, how does authentication work at the Indigo web server? Is it digest, is it cleartext, can it be Kerberized? Be used with form auth? Is it claims-aware? I sure there must be some way of sending always the same authentication data from the proxy while allowing users to authenticate with directory credentials, Federation has other perks, like Azure MFA (think a super-secure-huge-ass-Indigo Reflector), Okta, integration with Atlassian Confluence and like a million more we'd like to continue (or start) using. Our phones are our keys to home, more importantly, they are our garage doors openers, so it's sort of crucial to have that functionality at a tap's distance and not to be fiddling with credentials input while driving.

When Indigo was first put behind ADFS not much was researched because there were a lot of things to do still, now I have more time plus a Nintendo-playing-helper friend who can keep me awake, and if I have to learn REST and any of those technologies with acronyms I can only assume are based on irony so be it, I just need a little starter...OAuth?

I hope emails don't go to junkmail this time. :/

Details done, my question is, how does authentication work at the Indigo web server? Is it digest, is it cleartext, can it be Kerberized?

The REST API (using the web server) requires Digest authentication. If you want to change that, the code is all there in the Indigo folder. It's based on the cherrypy http server.

I use L2tp over IPsec VPN when I am remote. The tunnel is encrypted end to end.

Client behaves as if it is on the the LAN.

Have not played with the technology you use.

Indigo server use digest based authentication.

PS: I believe that security needs to be handled by network devices (router firewalls). I put a small router(< $50> in front of each critical device on the local network. Firewall rules are setup as appropriate for the IoT device/server. A further benefit is that many IoT devices cannot handle multicast/broadcast traffic that we find on modern networks. All this traffic get blocked by puttting a router in front of the IoT device.

I thought this died but it just was on an email account not on my phone.

Can @ mentions be done here?--I'll see.

Thanks @FlyingDiver, I figured as much, I'm going to try learning some of that cherrypy, I'm kinda loving the name. Honestly I've bothered so much setting up Indigo as my needs were fulfilled quickly and I just stayed there. I have no excuse for that though.

@lalisingh, thanks, IKEv2 also uses IPsec for encryption for the authentication and another cryptoset for the tunnel itself plus it will redial the tunnel if, for instance, you move from cellular to Wi-Fi and back or briefly lose coverage, little things that would kill an L2TP link, it's standards-based meaning it's just about in any device but still, it isn't perfect. Federation on the other hand doesn't need tunneling, basically two servers establish a trust relationship between them and a user registered on one of their databases gives permission to exchange some or all of his/her data in the form of claims, sort of like tickets or coupons, you contact both to start the exchange but the exchange is done directly between them with no passwords passed around. This is what happens when you log in using your Facebook/Twitter/etc credentials to some random website.

It obviously is more complicated that direct tunneling but it's super expandable and once you get around the basics it is so cool what you can do with it. It nearly drove me insane trying to set up my first trust though. On your access concentrator you should try setting up IKEv2, just make sure the certificates match the hostname and you'll be fine, you'll love it when it magically redials, It's like you're forever home.

Anyway, time to get me py now. <3