Identity Server security support

[jkonicki]

Along with the OpenID and OAuth2 that we currently offer, Identity Server should be the next support path we take for single sign-on, identity management, authorization, and API security.

[tscrypter]

Since Identity Server 4 operates as an OpenID Connect and OAuth 2.0 framework, is the intention that the SSO configuration of the Steeltoe app remains similar but Identity Server would replace UAA Server or Pivotal Single Sign-on service?

[TimHess]

I think the idea here is making sure there's an opinionated way of establishing the connection with Identity Server, ideally creating an interchangeable setup where (similar to other areas of Steeltoe) you can switch your SSO server with just configuration or minimal code change. There may also be some need for a Kubernetes recipe here as well

[tscrypter]

Ok, that makes sense. I can start on identity server for SSO later this evening.

[tscrypter]

The solution I'm starting to go down is as follows:

Mutual TLS auth

CloudFoundry config

public void ConfigureServices(IServiceCollection services)
{
    services.AddCloudFoundryCertificateAuth(Configuration);
    services.AddControllers();
}

becomes

public void ConfigureServices(IServiceCollection services)
{
    services.AddIdentityServerCertificateAuth(Configuration);
    services.AddControllers();
}

The configuration that will be required is a config setting for the certificate and privateKey used for the authentication. This approach will basically adhere to this process: http://docs.identityserver.io/en/latest/topics/mtls.html.

I'm going to add additional comments talking about the other approaches for SSO/Jwt.

[tscrypter]

The solution I'm starting to go down is as follows:

SSO

CloudFoundry config

services.AddAuthentication((options) =>
            {
                options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = CloudFoundryDefaults.AuthenticationScheme;
            })
            .AddCookie((options) =>
            {
                options.AccessDeniedPath = new PathString("/Home/AccessDenied");
            })
            .AddCloudFoundryOpenIdConnect(Configuration);

becomes

services.AddAuthentication((options) =>
            {
                options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = IdentityServerDefaults.AuthenticationScheme;
            })
            .AddCookie((options) =>
            {
                options.AccessDeniedPath = new PathString("/Home/AccessDenied");
            })
            .AddIdentityServerOpenIdConnect(Configuration);

The additional configuration options that will need to be added will be the details typically provided in the p-identity auth mySSOService after it's been configured (clientId, clientSecret, identityServerUri, scopes, etc...).

JWT

Similar to the SSO approach, there would be a corresponding AddIdentityServerJwtBearer(Configuration). Similar additional configuration details would need to be provided as with the SSO.

[TimHess]

@tscrypter have you made much progress or found anything interesting here?

I don't want to derail any progress you may have made, but I was talking with @macsux about this issue and since Identity Server's purpose really boils down to "easily customized Identity Provider that's standards compliant", a valuable solution here might need to be based on a non-trivial ID Server template since MSFT's libraries are theoretically sufficient for the standard scenarios.

Specifically it might be interesting to do all this with a deeper Kubernetes integration, such that Kubernetes is the data store and some app credential setup actions could happen automatically when apps are deployed to the cluster... We can talk more about this if you aren't already far down a different path

Thoughts?

[tscrypter]

@TimHess I'm not far down an implementation, am more than happy to pivot. Most of my progress has been on trying to identify options for the end user to swap identity providers with minimal code changes. The scenarios I mention in the comments above are the simpler cases (mostly looking at the security samples and making sure to have parody), and thinking through them did allow me to realize that their implementation's don't really save the end user much code compared to using MSFT's libraries.

I think having an opinionated approach to easily wire up ID Server via some Kubernetes configuration would be more interesting and likely add more value.

[TimHess]

@tscrypter I chatted with @macsux about this today and got a little more in depth with the above... At this point I think this conversation is better suited for our Kubernetes incubator project and have started logging some issues over there.

If we all agree this idea is best suited for that initiative then I think we can just close this issue

[TimHess]

Closing due to lack of interest. If you would like to see this supported, please respond to this issue