This one is interesting to explore.
Any tips to get started?
The reason why this took my interest is that I am looking for a way for an identity to provide single sign on capabilities into applications. This is what I am working up to over the next month.
Is this possible? I don't see why not as the user is already authenticated with strong identity.. but are unsure of how to connect this to a username in an application
The Ziti LDAP client was created to allow customers to connect an on-prem / hosted Microsoft Active Directory to the NetFoundry SaaS platform (for client sync) with no inbound ports required on the customer premise. Currently, OpenZiti does not support application authentication, it only provides network authentication into the application. This topic has been discussion with no commitments or timelines as of yet.
1 Like
Just chatted internally and was told:
It’s something one of our engineers is looking into. Prob weeks out before we have something worth talking about. This would allow using the same identity to access both Ziti and the application, not specifically ldap
Fancy doing some beta testing when appropriate??
1 Like
Absolutely… please advise when the beta is available.
Will this be coming to the general ZAC console, or only with the SaaS platform?
In OpenZiti we have added the lower-level facilities necessary to validate signed security tokens (i.e. JWTs, x509 certificates) from external sources (REST API /cas
and /ext-jwt-signers
in combination with /auth-policies
). Those facilities should allow open source adopters to create their own integrations with identity providers to facilitate SSO into Ziti.
If one is embedding OpenZiti in their own application, the external credentials provided to their application to connect to Ziti can also be sent to the target service. The target service would also need to trust the same IDP that Ziti does. The only piece missing that I’m aware of is that the SDKs do not allow JWT credentials to be passed in externally for authentication to Ziti (coming soon). However, they can be provided for the target service by the embedding application (e.g. Ziti auth using x509, target service using external JWT).
Turning Ziti into an identity provider is an interesting topic that has been brought up. This would require other systems to trust the security keys (x509, JWT, etc) provided by Ziti. There are enough pieces in place to cobble something together with x509 certificates now. However, there are issues with revocation as Ziti currently does not expose revocation facilities (CRL, OCSP, etc). Without those basic capabilities, I am hesitant to encourage anyone to go down this path in production environments.
All that said, specific IDP integrations will most likely never be in OpenZiti proper and would be relegated to the SaaS platform. My current standpoint is that OpenZiti takes the meat-and-potato approach of providing the basic facilities and allow others to construct gourmet meals.
1 Like
Great feedback and insights…
A simple thing that I have explored with the SDKs is that you can gain access to the name of the identity that is being used to host the service. In the SDK… you can then add authentication headers etc as needed… though I have not done this yet.
I think the means to easily implement device level posture checks is a nice starting point… because you can pass it through to the app… and if it does not match… the login will fail… even with a right username and password combination