Каковы потенциальные проблемы с этой схемой безопасности WebService?

Question

Каковы потенциальные проблемы с этой схемой безопасности WebService?

Попробуй это ... Это может помочь тебе ...

    let result = [];
    companies.forEach(company => {
        let tempCompany = {...company};
        factories.forEach(factory => {
            let tempArray = factory.companies.filter(item => item === company.id);
            if(tempArray.length > 0) {
                tempCompany.factory = factory.name;
            }
        });

        result.push(tempCompany);
    });

5

security web-services

задан 8 revs 8 October 2008 в 12:07

4 ответа

Другие вопросы по тегам:

security web-services

Похожие вопросы:

score 2 · Answer 1

Хорошо, заменяя мои более старые ответы, надо надеяться, лучшим.

То, что Вы описываете, должно работать, если у Вас есть способ надежно обменяться данными между Вашими сервисами. Например, если Ваши сервисы совместно используют секретный ключ с Сервисом Авторизации, можно использовать этот ключ для получения соли.

BTW, я не знаю, что достаточно криптографии говорит, достаточно ли безопасно добавить секретную соль + хеш (хотя кажется прекрасным); я вполне уверен, это безопасно к HMAC с секретным ключом или закрытым ключом. Вращение ключей является хорошей идеей, таким образом, Вы все еще имели бы главный ключ и распространили бы новый ключ подписи.

Другие проблемы с Вашим подходом то, что (a) Вы - жесткое кодирование логика хеширования в каждом сервисе и (b) сервисы могли бы хотеть получить более подробные данные от Сервиса Авторизации, чем просто ответ "да"/"нет". Например, можно хотеть, чтобы Сервис Авторизации вставил в заголовок, что этот пользователь принадлежит ролям A и B, но не C.

Как альтернатива, можно позволить Сервису Авторизации создать новый заголовок с любой интересной информацией, которую он имеет, и подпишите тот блок.

На данном этапе мы обсуждаем реализацию Единой точки входа. Вы уже знаете о спецификациях безопасности WS. Этот заголовок, который я описал, много походит на утверждение SAML.

Вот статья об использовании безопасности WS и SAML для Единой точки входа.

Теперь, я не знаю, нужно ли Вам все это... также существуют промежуточные решения. Например, Сервис Авторизации мог подписать исходный блок Имени пользователя; если Вы волнуетесь об общедоступной/частной crypto производительности, и Вы в порядке, совместно используя секретные ключи, Вы могли бы также использовать секретный ключ для подписания вместо общественности/закрытых ключей.

score 4 · Answer 2

Фундаментальная проблема с Вашей схемой состоит в том, что Вы не используете стандартную платформу или реализацию. Это независимо от каких-то конкретных достоинств Вашей схемы самой.

Причина проста, безопасность (криптография в особенности) очень, очень сложна и в значительной степени невозможна разобраться. Используйте общий инструмент, который устойчив, хорошо понятый и доказанный.

См.: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss для получения дополнительной информации о безопасности WS.

Большинство платформ (.NET/JavaEE и т.д.) будет иметь встроенную поддержку (до некоторой степени) безопасности WS.

Если Вы верите своему плану быть лучше в некотором роде, чем стандарты, я предлагаю, чтобы Вы описали его как статья и отправили его для экспертной оценки (наряду со ссылочной реализацией), но НЕ использовали его для обеспечения приложения.

РЕДАКТИРОВАНИЕ для ответа на Редактирование OP: Я думаю, что Вы путаете роли Аутентификации и авторизации немного, которую легко сделать...

Список Маркера безопасности (или подобный) в схемах должен Аутентифицировать отправителя сообщения - в основном, отправитель, кем они должны быть. Как Вы справедливо указали, Аутентификация не подразумевает ничего, о которых базовых ресурсах отправитель должен быть предоставленным доступом к.

Авторизация является процессом, посредством чего Вы берете аутентифицируемого отправителя и применяете некоторый набор полномочий так, чтобы можно было ограничить объем доступа. Обычно платформы не будут делать авторизации по умолчанию, Вы или должны включить ее путем создания некоторой формы ACL, или путем расширения некоторого интерфейса типа "Менеджера безопасности".

В действительности идея состоит в том, что уровень Authentication говорит Вам, кто пытается получить доступ к Page и оставляет его до Вас, чтобы решить, разрешен ли тот человек получить доступ к Page.

Вы никогда не должны хранить информацию о правах и полномочиях в самом сообщении - получатель должен проверить права против своего ACL (или база данных или безотносительно) для каждого сообщения. Это ограничивает Ваше воздействие, должен кто-то выяснять, как изменить сообщение.

score 1 · Answer 3

Лично я не вижу, что Вы имеете любые проблемы там, пока у Вас есть централизованная базовая платформа для поддержки проверки значений SecurityToken.

score 0 · Answer 4

В первую очередь, читайте сообщение @CJP, он высказывает точное мнение и актуальный вопрос.
Если Вы хотите идти вперед и прокрутить его сами так или иначе (возможно, у Вас действительно есть серьезное основание для него), я сделал бы следующие моменты:

Вы говорите об Услуге аутентификации, НЕ сервисе авторизации. Только для проверки Вы знаете то, о чем Вы говорите...?
Во-вторых, необходимо отделиться между солью (который не является секретным), и ключ (который является). У Вас должно быть хэширование по ключу (например, HMAC), вместе с солью (или включенный соленый хеш. Походит на тестовую систему.). Соль, как отмечено, не является секретной, но должна быть изменена ДЛЯ КАЖДОГО МАРКЕРА и может быть включена в заголовок; ключ ДОЛЖЕН быть секретным и изменить, каждый день хорошо. Конечно, удостоверьтесь, что Вы используете сильный хеш (например, SHA-256), надлежащие методы управления ключами, и т.д. и т.д.

Снова, я убеждаю Вас пересмотреть прокрутку Вашего собственного, но если необходимо выйти самостоятельно...