내가 제어하지 않는 Shibboleth 서비스 공급자/신뢰 당사자에게 AD FS 3.0 ID 공급자 (IDP)를 연결해야합니다. Unfortunatley, AD FS 및 Shibboleth는 클레임 / 속성에 대해 동일한 형식을 사용하지 않습니다.SamAccountName을 통해 Shibboleth에 AD FS 3.0을 연결하십시오. 이름 ID
많은 정보가 웹에 있습니다. 두 가지 규칙 (Active Directory에서 값을 검색하는 규칙과 Shibboleth의 예상과 일치하도록 변환하는 규칙)이 필요하지만 그 중 많은 부분이 AD FS 2.0 용으로 작성되었거나 전자 메일 주소를 이름 ID로 사용합니다 (이 경우 SamAccountName이 필요합니다).
Shibboleth에서 허용하는 windows-account-name을 사용하여 클레임을 생성하려면 어떻게해야합니까?
나는 마침내 여기 해답을 발견 : 목록을 연결
는https://cccnext.jira.com/wiki/spaces/CSF/pages/147817839/Attributes+for+the+Proxy+AD+FS
사용자 정의 SAMAccountName을/창 - 계정 이름을 포함하여 Active Directory의 필드의 수의 쌍을 지배.
규칙은 I는 다음과 같이 사용 :
@Rulename="Get sAMAaccountName"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> add(store = "Active Directory", types = ("urn:oid:1.2.840.113556.1.4.221"), query = ";sAMAccountName;{0}", param = c.Value);
@Rulename="Convert sAMAccountName/uid xml"
c:[Type == "urn:oid:1.2.840.113556.1.4.221"]
=> issue(Type = "urn:oid:0.9.2342.19200300.100.1.1", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrname-format:uri");
이는 PowerShell 스크립트의 일부로 포함되었다,하지만 당신은 사용자 지정 클레임 규칙을 추가하여 AD의 FS 인터페이스를 통해 추가 할 수 있습니다.
Shibboleth 끝을 변경해야 할 수도 있습니다. 이 기사를 읽기 전에 상대방의 서비스 기술자가 제외 된 속성을보고하고 그 속성을 허용하도록 변경했습니다. 그러나 그것은 다른 규칙 집합이었습니다. 이 규칙 세트가 그 변화를 이용하고 있는지 아닌지 나는 모른다.