in. 클레임 기반 ID 프레임 워크레코드에 대한 액세스 제한. 클레임 기반 권한은 좋은 생각입니까
계정 (특정 계정 # 123456)에 대해 작업 (보기 또는 편집)을 수행하도록 사용자를 제한하려는 경우. 나는 은행 계좌처럼 사업체에 관해 이야기하고 있습니다.) 보거나 편집 할 수있는 각 계좌에 대한 소유권 주장을 만드는 것이 좋은 생각입니까?
세트에 많은 소유권 주장이있는 단점은 무엇입니까? 시스템 관리자는 시스템의 모든 계정에 액세스하여 수백 가지의 클레임을 만들 수 있습니다 (각 계정마다 두 개 이상일 수도 있음)
큰 클레임 집합의 가장 즉각적인 결과는 토큰이 네트워크를 통해 관련된 모든 시스템. 예를 들어 WIF는 기본적으로 토큰을 직렬화하여 쿠키에 저장합니다. 따라서 실제로는 저장할 수있는 데이터의 양이 제한적입니다. 이 문제를 처리하는 다른 방법이 있지만 기본 문제는 계속됩니다.
두 번째 고려 사항은 사용자와 계정 간의 연결을 누가 그리고 어디에서 관리 할 것인가입니다. 그것이 특정 애플리케이션 일 경우, 그러한 연관을 중앙 STS (클레임 발급자)로 푸시 할 가능성은 거의 없습니다. 그러면 사용자 (ID 제공자 : IdP)를 식별하는 STS와 IdP에서 발급 한 토큰을 특정 응용 프로그램의 밑줄 (특정 사용자의 계정 목록 포함)로 변환 할 응용 프로그램 특정 STS가있는 2 STS로 끝납니다.
그런데 사용자와 그의 계정 간의 연결이 많은 응용 프로그램에서 재사용 가능한 것일 수 있습니다. 그런 다음 특수 STS 뒤에 넣는 것이 타당 할 수 있습니다.
잠재적 인 불필요한 정보 공개가 세 번째 고려 사항입니다. 응용 프로그램은 사용자 X가 계정 123에 액세스 할 수 있는지 알아야합니다. 사용자 X가 액세스 할 수있는 모든 계정 목록을 제공하면 필요한 추가 정보가 공개됩니다.
일반적인 지침에 따라 "거친 나뭇결"특성이 더 좋습니다. "세분화 된"액세스 제어는 인프라 최적화를 사용할 수있는 응용 프로그램에서 처리하는 것이 좋습니다.
다음은 극단적 인 예입니다. 파일 시스템을 상상해보십시오. 사용자가 액세스 할 수있는 파일의 이름을 클레임으로 인코딩 하시겠습니까? 가능성은 수백만으로 끝날 수도 있기 때문에 ...
또 다른 극단적 인 예 : 데이터베이스에 행 수준 보안을 구현하려는 경우. 각 사용자에 대한 row_id의 클레임을 인코딩하겠습니까? 다시는있을 수 없기 때문에 응용 프로그램별로 매우 다양하며 데이터베이스 쿼리로 행 필터링을 해결하는 것이 더 쉽고 (훨씬 효율적입니다)
사용자별로 행 수준 보안에 적합한 선택은 무엇입니까? –
왜 각 역할에 권한을 부여 할지를 직접 구현하지 않고 클레임 기반 ID 프레임 워크를 사용하기로 결정한 이유는 무엇입니까? 예 : 모든 비즈니스 계정을 볼 수있는 권한이있는 BusinessAccountMaintenance 역할 –
아직 사용하지 않습니다. 단지 이론적 인 질문입니다. 클레임 기반 ID 프레임 워크에 대한 내 머리를 감싸려고합니다. – Vitalik