Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Toruń 28/29.10.2014. Po udanym uwierzytelnieniu IdP może przekazać do SP dodatkowe informacje o użytkowniku – IdP korzysta ze wskazanego źródła danych.

Podobne prezentacje


Prezentacja na temat: "Toruń 28/29.10.2014. Po udanym uwierzytelnieniu IdP może przekazać do SP dodatkowe informacje o użytkowniku – IdP korzysta ze wskazanego źródła danych."— Zapis prezentacji:

1 Toruń 28/29.10.2014

2 Po udanym uwierzytelnieniu IdP może przekazać do SP dodatkowe informacje o użytkowniku – IdP korzysta ze wskazanego źródła danych w celu pobrania informacji o użytkowniku, konfiguracja IdP ustala, jakie atrybuty mogą być udostępniane (zbiór A) – podczas rejestracji SP w federacji wskazywane są wymagania SP odnośnie atrybutów, w metadanych SP powinny być wymienione atrybuty, z których SP korzysta (zbiór B) – SP otrzymuje przekrój zbiorów A i B IdP powinien wysyłać do SP tzw. pseudoanonimowy identyfikator, który jest unikatowy dla danego użytkownika w odniesieniu do tej usługi (SP)

3 Schemat eduPerson definiuje atrybut eduPersonTargetedID (urn:oid:1.3.6.1.4.1.5923.1.1.1.10) jako – A persistent, non-reassigned, opaque identifier for a principal czyli – identyfikator stały (nie zmieniający się przy kolejnych logowaniach), niepowtarzalny, przezroczysty, czyli nie ujawniający tożsamości użytkownika

4 Identyfikator ma format określany w SAML2 jako "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" Specyfikacja OASIS Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2, w rozdziale 8.3.7 definiuje Persistent Identifier następująco: – jest to stały, transparentny identyfikator, specyficzny dla danego użytkownika, IdP oraz SP lub stowarzyszenia SP (affiliation) – identyfikator MUSI być generowany przez IdP przy użyciu liczby losowej nie mającej żadnego powiązania z identyfikatorem użytkownika – długość identyfikatora nie może przekroczyć 256 znaków

5 Atrybut eduPersonTargetedID został zdefiniowany na potrzeby tworzenia trwałego identyfikatora w Shibboleth, gdy korzystano jeszcze z SAML 1.1 Wartość eduPersonTargetedID była przekazywana jako wartość atrybutu SAML Obecnie rekomendowanym sposobem przekazywania trwałego identyfikatora do SAML 2.0 SP jest umieszczanie go w elemencie Subject przekazywanego poświadczenia (assertion)

6 <saml2:NameID xmlns:saml2=" urn:oasis:names:tc:SAML:2.0:assertion " Format=" urn:oasis:names:tc:SAML:2.0:nameid- format:persistent " NameQualifier=" https://idp.example.org/idp/shibboleth " https://idp.example.org/idp/shibboleth " SPNameQualifier="https://sp.example.org/shibbol eth">https://sp.example.org/shibbol eth" 84e411ea-7daa-4a57-bbf6-b5cc52981b73

7 Alternatywne podejście to przekazanie persistent ID jako atrybutu o nazwie formalnej " urn:oid:1.3.6.1.4.1.5923.1.1.1.10 " <saml2:Attribute xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" FriendlyName="eduPersonTargetedID"> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://idp.example.org/idp/shibboleth"https://idp.example.org/idp/shibboleth" SPNameQualifier="https://sp.example.org/shibboleth">https://sp.example.org/shibboleth" 84e411ea-7daa-4a57-bbf6-b5cc52981b73

8 Tworzenie trwałego identyfikatora przebiega następująco: – przygotowujemy konektor do bazy danych (data connector) o nazwie StoredID – służy on do tworzenia / pobierania wartości – utworzenie definicji atrybutu operującego na StoredID Tworzymy bazę danych o nazwie shibboleth bazie danych i tablicę shibpid i dostosowujemy plik konfiguracji Shibboleth IdP – conf/attribute-resolver.xml

9 CREATE TABLE IF NOT EXISTS shibpid ( localEntity TEXT NOT NULL, peerEntity TEXT NOT NULL, principalName VARCHAR(255) NOT NULL DEFAULT '', localId VARCHAR(255) NOT NULL, persistentId VARCHAR(36) NOT NULL, peerProvidedId VARCHAR(255) DEFAULT NULL, creationDate timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, deactivationDate TIMESTAMP NULL DEFAULT NULL, KEY persistentId (persistentId), KEY persistentId_2 (persistentId, deactivationDate), KEY localEntity (localEntity(16), peerEntity(16), localId), KEY localEntity_2 (localEntity(16), peerEntity(16), localId, deactivationDate) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;

10 <resolver:DataConnector xsi:type="dc:StoredId" xmlns="urn:mace:shibboleth:2.0:resolver:dc" id="storedID" sourceAttributeID="eduPersonPrincipalName" generatedAttributeID="persistentId" salt="1qaasfkdakdakakakagkalkg"> <dc:ApplicationManagedConnection jdbcDriver="com.mysql.jdbc.Driver" jdbcURL=" jdbc:mysql://localhost:3306/shibboleth?autoRecon nect=true " jdbcUserName="shibboleth" jdbcPassword="zaqWSX12" />

11 <resolver:AttributeDefinition xsi:type="ad:SAML2NameID" id="eduPersonTargetedID" sourceAttributeID="persistentId" nameIdFormat= " urn:oasis:names:tc:SAML:2.0:nameid-format:persistent "> Targeted ID Targeted ID

12 Targeted ID: A unique identifier for a person, different for each service provider. Targeted ID: identyfikator specyficzny dla danego SP <resolver:AttributeEncoder xsi:type="enc:SAML2XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" />

13 <resolver:AttributeDefinition id="persistentId" xsi:type="ad:Simple" sourceAttributeID="persistentId"> <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat= "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />

14 <resolver:AttributeDefinition xsi:type="ad:SAML2NameID" id="eduPersonTargetedID" sourceAttributeID="persistentId" nameIdFormat="urn:oasis:names:tc:SAML:2.0:nameid- format:persistent"> Targeted ID Targeted ID: A unique identifier different for each SP Targeted ID: unikatowy identyfikator specyficzny dla SP <resolver:AttributeEncoder xsi:type="enc:SAML2XMLObject" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" friendlyName="eduPersonTargetedID" />

15 Atrybuty eduPersonTargetedID/persistentID są generowane przez dodawany przez dedykowane filtry: – saml:PersistentNameID – generuje identyfikator persistent Id o formacie urn:oasis:names:tc:SAML:2.0:nameid- format:persistent na podstawie wskazanego atrybutu oraz wartości secretsalt ustalonej w pliku config/config.php – saml:SQLPersistentNameID – generuje identyfikator persistent Id i umieszcza go w bazie danych SQL – SSP musi mieć skonfigurowany dostęp do zasobów SQL, w tym celu należy ustawić w pliku config/config.php opcję store.type 'store.type' => 'sql',

16 'authproc.idp' => array( 1 => array( 'class' => 'saml:SQLPersistentNameID', 'attribute' =>'eduPersonPrincipalName', 'AllowCreate' => "true" ),

17 90 => array( 'class' => 'consent:Consent', 'store' => 'consent:Cookie', 'focus' => 'yes', 'checked' => TRUE ), 95 => array( 'class' => 'saml:PersistentNameID2TargetedID', 'attributename' => 'eduPersonTargetedID', 'nameId' => TRUE ), 100 => array( 'class' => 'core:AttributeMap', 'name2oid'), ),

18 eduPersonTargetedID powinien być wysyłany w postaci NameID, w tej sytauacji trzeba zadeklarować w metadata/saml20-idp-hosted.php: 'attributeencodings' => array( 'urn:oid:1.3.6.1.4.1.5923.1.1.1.10' => 'raw', ), – raw oznacza, że atrybuty mają być przekazywane bez żadnej modyfikacji, dzięki temu jest możliwe przekazywanie odpowiedzi w postaci XML

19


Pobierz ppt "Toruń 28/29.10.2014. Po udanym uwierzytelnieniu IdP może przekazać do SP dodatkowe informacje o użytkowniku – IdP korzysta ze wskazanego źródła danych."

Podobne prezentacje


Reklamy Google