Расположение ключей защиты данных ASP.NET Core OpenIdConnectServer

Привет,

В моем приложении ASP.NET Core я использую OpenIdConnectServer для аутентификации API. Все работает нормально.

Но есть одна вещь, которую я не могу решить - как установить пользовательскую папку для сохранения ключей подписи токена?

В конфигурации службы у меня есть:

services.AddDataProtection()
        .PersistKeysToFileSystem(new DirectoryInfo(@"keys/"));

После первого запуска там создается ключ приложения. Но OpenIdServer как-то сам распоряжается ключами.

app.UseOpenIdConnectServer(options => {
    ...
    options.DataProtectionProvider = app.ApplicationServices.GetDataProtectionProvider();
    ...
});

Несмотря на это, ключ подписи учетных данных создается в расположении по умолчанию:

 A new RSA key ... persisted on the disk: /home/.../.aspnet/aspnet-contrib/oidc-server/<some guid>.key.

Это баг или фича? Как заставить сервер хранить ключи еще и в папке keys/?

Аннотация – зачем я это делаю:

Моя идея состоит в том, чтобы создать API из n док-образов этого, спрятать его за балансировщиком нагрузки и запустить где-нибудь в облаке. Проблема в том, что когда каждый экземпляр в докере создает свой собственный ключ приложения и подписи, зашифрованный токен авторизации не будет работать ни для какого другого экземпляра, кроме того, который создал и подписал токен своим ключом. Поэтому я пытаюсь распространять одни и те же ключи на каждый работающий образ докера. В предопределенную папку приложения, если это возможно.

Или есть лучший подход или лучшая практика?

Заранее спасибо.


c# asp.net-core openid-connect aspnet-contrib asp.net-core-1.0
person rudolfdobias    schedule 08.10.2016    source источник
comment
К вашему сведению, промежуточное программное обеспечение сервера OIDC не меняет способ управления ключами DataProtection, но это не единственные используемые им ключи, поскольку на самом деле существует 2 отдельных механизма сериализации, как описано в stackoverflow.com/questions/38541772/авторизация-через-jwt-токен/. Отладочное сообщение, которое вы видите, регистрируется внутренней функцией генерации ключей RSA, которая создает асимметричные ключи для подписи id_token. Обратите внимание, что эта функция предназначена в основном для целей разработки и будет удалена в следующей бета-версии (beta7).   -  person Kévin Chalet    schedule 09.10.2016

Ответы (1)


arrow_upward
5
arrow_downward

Ну, я понял это.

Во-первых, мы должны сгенерировать сертификат x509 (с закрытым ключом), как описано здесь

openssl genrsa -out private.key 1024
openssl req -new -x509 -key private.key -out publickey.cer -days 365
openssl pkcs12 -export -out certificate.pfx -inkey private.key -in publickey.cer

Скопируйте его в нужную папку, в данном случае key/certificate.pfx.

Затем аккуратно вставьте новый сертификат в OpenIdConnectServer:

appsettings.json

"Keys": {
    "CertificatePath": "keys/certificate.pfx",
    "CertificatePassword": "<password you provider>"
}

Startup.cs

private X509Certificate2 CreateOauthCertificate(){
        var path = Configuration["Keys:CertificatePath"];
        var password = Configuration["Keys:CertificatePassword"];
        return new X509Certificate2(path, password);
    }

Starup.cs — Настройка

app.UseOpenIdConnectServer(
    ...
    options.SigningCredentials.AddCertificate(CreateOauthCertificate());
    ...
});

Теперь мне любопытно, есть ли лучший способ или нет.

Но это работает.

С уважением

person rudolfdobias    schedule 08.10.2016
comment
Я задался вопросом. Если вы сохраните CertificatePath и CertificatePassword в переменных среды (или сохраните с помощью инструмента управления секретами) вместо appsettings.json, разве это не будет работать должным образом? - person adem caglin; 09.10.2016
comment
Это именно то, что нужно сделать (это даже станет обязательным с beta7, так как функция генерации ключей RSA будет удалена). - person Kévin Chalet; 09.10.2016
comment
@ademcaglin Думаю, это тоже должно сработать. Я выбрал подход json для наглядной демонстрации здесь. - person rudolfdobias; 09.10.2016
comment
Спасибо @rudolfdobias. Я просто хотел узнать, есть ли особая причина использования настроек приложений (мне было интересно, является ли это конкретным случаем докера). - person adem caglin; 09.10.2016
comment
@ademcaglin В этом случае я загружаю файлы конфигурации вместе с ключами из AWS S3 во время сборки CI. Сертификат хранится в каком-то двоичном формате, и я все равно не мог вставить переменную env. И в json есть много настроек для определения его в envs. Лучшим подходом может быть подключение к S3 напрямую из запуска приложения через файловую систему AWSSDK.S3. - person rudolfdobias; 09.10.2016