시스템 사용자
시스템 사용자는 외부 API 레이어가 사용자별로 권한을 부여받도록 하면서 내부 서비스 권한을 간편하게 관리하기 위해 설계된 ThingWorx의 시스템 객체입니다. 시스템 사용자는 선택 사항입니다. 서비스에 시스템 사용자가 지정되지 않은 경우 ThingWorx에서는 모든 후속 래핑된 서비스를 요청한 사용자의 권한을 확인합니다.
일반적으로 사용자가 서비스를 호출할 때 해당 사용자는 서비스를 호출할 권한과 초기 호출된 서비스 내에서 다른 서비스를 호출할 권한이 있어야 합니다. 예를 들어, 사용자는 내부적으로 QueryStreamEntriesWithData 및 GetDataTableEntryByKey를 호출하는 사물에서 GetMachineRunTimeHistory 서비스를 실행합니다. 시스템 사용자를 사용하지 않고 GetMachineRunTimeHistory를 호출한 사용자는 QueryStreamEntriesWithData 및 GetDataTableEntryByKey를 실행할 명시적 권한도 필요합니다.
시스템 사용자를 사용하면, 서비스 또는 구독(래핑된 서비스 호출) 내에서 사용자 정의 서비스가 호출되고 시스템 사용자가 서비스를 실행할 수 있도록 허용된 경우 이벤트, 스크립트 또는 서비스의 시퀀스를 처음 트리거한 사용자에 상관없이 서비스가 실행될 수 있습니다. 그러나 사용자는 명시적으로 허용되지 않는 한 래핑된 서비스 자체(위 예에서 QueryStreamEntriesWithData 또는 GetDataTableEntryByKey)를 직접 호출할 수 없습니다.
이를 통해 관리자는 명시적 액세스가 허용된 사용자 및 그룹을 통해 외부적으로 액세스 가능한 표면 API를 잠글 수 있습니다. 항상 사용자 전파를 통해 서비스 호출을 래핑하는 것이 좋지만 시스템 사용자는 권한 관리 관점에서 내부 서비스 호출을 간편하게 관리할 수 있습니다.
관리자 그룹에 시스템 사용자를 추가할 수 있습니다. 이렇게 하면 서비스 호출 내에 중첩된 모든 항목에 대한 전체 권한이 모든 사용자에게 부여됩니다. 서비스를 호출하는 사용자의 권한에 상관없이 사용자 정의 서비스 내에서 호출된 모든 서비스가 성공합니다.
시스템 사용자는 사물을 질의할 때 사용자의 표시 유형을 확장하지 않습니다. 사용자가 볼 수 있는 표시 유형 권한이 없는 사물을 검색하는 데 시스템 사용자를 사용할 수 없습니다. 이를 보여주는 다음 예를 살펴보십시오.
1. 사물 템플릿 Template1을 상속하는 5개의 사물인 T1, T2, T3, T4, T5 및 두 명의 사용자인 User1 및 User2가 있습니다.
2. User1은 T1 및 T2에 대한 표시 유형 권한을 보유하고 있고, User2는 T4 및 T5에 대한 표시 유형 권한을 보유하고 있습니다.
3. 서비스 실행 권한은 Template1에 대해 QueryImplementingThings의 시스템 사용자에게 부여되며 이름이 CallQueryImplementingThings인 사용자 정의 서비스가 생성됩니다. 이 서비스는 내부적으로 QueryImplementingThings를 호출하고 User1과 User2에게 서비스 CallQueryImplementingThings에 대한 서비스 실행 권한을 제공합니다.
4. User1이 CallQueryImplementingThings 서비스를 실행하면 결과에서 T1과 T2를 봅니다.
5. User2가 CallQueryImplementingThings 서비스를 실행하면 결과에서 T4와 T5를 봅니다.
 |
보안을 무시하거나 보안 응용 프로그램을 신중하게 설계하고 구현해야 할 필요성을 완화하기 위해 시스템 사용자를 사용하는 것은 권장되지 않습니다. 시스템 사용자 사용은 사용자 전파 사례에 대한 일반적인 해결책이 아닌 특정 사용 사례로만 제한하는 것이 좋습니다.
|
시스템 사용자 예
시스템 사용자에게 서비스를 실행할 수 있는 권한을 부여한다는 것은 모든 사용자가 사용자 정의 서비스 내에서 해당 서비스를 실행할 수 있는 권한은 부여받지만 해당 서비스를 직접 호출할 수 있는 권한을 반드시 부여받는 것은 아니라는 의미입니다. 시스템 사용자를 제대로 사용하려면 다음을 수행합니다.
1. 시스템 사용자에게 서비스를 실행할 수 있는 권한을 제공하되 해당 서비스의 권한을 제한하여 다른 사용자는 해당 서비스를 실행할 수 있는 권한이 없도록 합니다.
2. 제한된 서비스를 호출하는 사용자 정의 서비스를 작성한 다음 사용자에게 제한된 서비스가 아닌 사용자 정의 서비스를 실행할 수 있는 권한을 제공합니다.
3. 사용자는 제한된 서비스를 실행할 수 있는 권한이 없어도 사용자 정의 서비스를 실행할 수 있습니다.
예를 통해 이 개념을 더 자세히 설명하기 위해 다음 사용 사례를 살펴보겠습니다.
사용자에게 이름이 CustomService1인 특정 연결된 장치의 상태를 표시하는 사용자 정의 서비스를 작성하려고 합니다. 이를 위해 CustomService1은 DeviceFunctions 리소스에서 SearchDevices 서비스를 사용하여 플랫폼에 있는 모든 장치를 조회한 후 결과를 필터링하여 특정 장치만 반환할 수 있습니다.
그러나 권한 확인은 CustomService1은 물론 CustomService1 내에서 이루어지는 모든 서비스 호출에 대해서도 수행됩니다. 사용자가 CustomService1을 성공적으로 호출하려면 SearchDevices 서비스를 실행할 수 있는 권한이 있어야 하며, 그렇지 않은 경우 CustomService1 호출이 실패합니다. 사용자에게 SearchDevices를 호출할 수 있는 권한을 제공하는 것은 바람직하지 않습니다. 여기서는 모든 장치가 아니라 특정 장치의 상태에만 사용자가 액세스할 수 있도록 하려고 하기 때문입니다.
시스템 사용자를 사용하면 이 문제를 해결할 수 있습니다. 서비스가 직접 실행될 경우 해당 사용자의 권한을 확인하여 해당 권한이 있는지 결정합니다. 이는 모든 사용자 정의 서비스를 비롯한 모든 서비스에 해당합니다. 그러나 서비스가 사용자 정의 서비스 내에서 실행될 경우에는 실제로 두 가지 권한인 사용자의 권한과 시스템 사용자의 권한이 확인됩니다. 사용자 또는 시스템 사용자에게 사용자 정의 서비스 내의 서비스를 실행할 수 있는 권한이 있는 경우 사용자에게 내부 서비스를 실행할 권한이 있는 것처럼 내부 서비스가 실행됩니다. SearchDevices는 CustomService1 내에서만 호출되고 직접 호출되지 않으므로 시스템 사용자에게 SearchDevices를 실행할 수 있는 권한을 제공할 수 있습니다. 사용자가 CustomService1을 호출하면 권한 확인이 수행됩니다. 이 확인에서는 User1에게는 권한이 없지만 시스템 사용자에게는 권한이 있는 것으로 확인됩니다. 따라서 사용자에게 권한이 있는 것처럼 SearchDevices가 실행됩니다. 사용자가 SearchDevices를 CustomService1 내에서 호출하지 않고 직접 호출하려고 하면 시스템 사용자의 권한이 적용되지 않고 사용자에 대해 권한이 거부됩니다.
