Доступ к сторонним службам с аутентификацией

У меня есть приложение, которое звонит во внешние (сторонние) службы, и мне было интересно, могу ли я получить помощь в этом.

Я пытаюсь выяснить, как поступить с несколькими вещами, и мне было интересно, есть ли у вас какой-либо вклад и / или опыт в том, как справиться с определенной ситуацией.

  1. Мы хотим иметь возможность создать архитектуру, в которой служба обрабатывает сторонние вызовы, чтобы клиенту не нужно было знать, к какой службе он обращается. Например, если у нас есть способ интеграции со сторонней организацией, такой как DocuSign, для подписания документов, клиент должен просто иметь возможность вызывать службу на нашей стороне, которая определяет (на основе некоторых учетных данных, аренды и т. д.), с какой службой он интегрируется. . Однако я начал с создания интерфейса, который по-прежнему заставляет клиента определять, какую реализацию создавать и вызывать, и мы хотим попытаться разделить это, если это возможно. а. Позвоните в нашу службу «подписания документов», указав клиента и арендатора, с которым мы работаем, возможно, через токен доступа. б. Эта служба подписи документов затем должна будет указать, какие учетные данные ей нужны, и сообщить клиенту, как войти в эту службу. Например, он может захотеть перенаправить на сервер авторизации, чтобы получить токен доступа для отправки в нашу службу для совершения вызова.

  2. У нас также есть некоторая автономная обработка, которую необходимо будет выполнить, что может вызвать сторонние службы, которым требуется аутентификация, но нет клиента, который нужно запрашивать. Я пошел по пути хранения токена SAML и/или учетных данных пользователя, но это кажется очень небезопасным. Опять же, будучи псевдо-новичком в IdM, я не совсем уверен, как с этим справиться (гугл выдает всевозможные варианты, но большинство, если не все, кажутся очень небезопасными). Я полагаю, мы можем сделать что-то с шифрованием токенов и т. д., чтобы хранить их вместе с ним, чтобы затем вызвать соответствующие серверы авторизации, когда придет время для запуска задачи и получения токена.

Любые мнения о том, как правильно обращаться с ними?


rest bearer-token oauth identity ws-federation
person user3854454    schedule 20.10.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

ОК, прежде всего вам нужно учитывать, что вы используете сторонние API-вызовы, чтобы делать все, что вам нужно, поэтому первое, что вам нужно иметь в виду, это то, что вам обязательно понадобится токен доступа для ваших пользователей для доступа к этим API. .

Итак, если вы говорите, что у вас могут быть различные сторонние API для одного пользователя, вам может понадобиться создать абстрактный класс с методом CALL(), который будет переопределен конкретными классами (по одному для каждой третьей стороны). API), например:

public abstract class ApiData {

//Your variables

protected call(String url, //Some parameters) {
//default body
}

После этого вы можете создать класс, который переопределит класс ApiData. Например:

public class DocuSignApi extends ApiData {

//Your variables

@Override
private call(String url, //Some parameters) {
// APi call for DOCUSIGN
}

Таким образом, всякий раз, когда вы создаете пользователя внутри своей системы, вам нужно будет сохранить для него список ApiData, например:

public class MyUser {
// All parameters

private List<ApiData> apiCalls = new ArrayList<ApiData>();

}

При этом у вас будет для каждого пользователя все вызовы API, к которым он может получить доступ, вы можете выполнять итерацию по этому списку и для каждого элемента вызывать метод «call()», и он будет вызывать правильный сторонний API.

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

Я также предполагаю, что вы внедрили собственную службу входа в систему для своих пользователей. Я не уверен, что вы спрашивали, как лучше и безопаснее это сделать, но если это так, я приведу вам пример. У меня много логинов в некоторых проектах, которые я сделал, и я использую логин OAUTH. По сути, вы запрашиваете заголовком HTTP ваши учетные данные в зашифрованном виде, после чего вы позволяете пользователю войти в систему или нет, проверяя в своей базе данных правильность данных для входа. Если вход в систему выполнен успешно, вы создаете токен доступа, СОХРАНИТЕ этот токен доступа в своей базе данных (с датой создания) и возвращаете его своему пользователю, таким образом, вы также можете иметь функцию истечения срока действия токена, что является очень хорошей практикой. .

Надеюсь это поможет..

Ваше здоровье

person Cesar Villasana    schedule 20.10.2014