Introduction#
This document is a companion to the Feide Integration Guide. It is recommended to read that document for a conceptual and architectural introduction to Feide.
In this document you will find a more thorough discussion of the technical side of becoming a Feide integrated service provider. The first part of this document discusses how Feide implements SAML, and the next part gives an overview of the Feide user attributes.
SAML in Feide#
Security Assertion Markup Language (SAML) is a protocol framework for federated identity management. SAML is an XML-based standard.
The Feide federation consist of 3 parties:
The Feide Identity Provider (IdP).
The Service Provider (SP).
The Feide user.
There are many choices left to the developers when it comes to implementing SAML inside and across organizations. Interoperable SAML 2.0 Profile is an effort to specify a “least common denominator” for SAML federated Web based Single Sign-On (SSO). The Feide configuration is based on this profile and recommendations for single logout (SLO).
There are pre-made SAML handling libraries for the major web development platforms. We urge you to use one of these unless you have a compelling reason to do otherwise. To do a robust implementation of SAML protocol handling is a major undertaking. There is more about available software and integration in Feide Integration Guide in the chapter Choose and deploy SAML 2.0 Service Provider software.
SAML Messages#
During user login and logout SAML messages are communicated between the SP and IdP. How the messages are transmitted between IdP and SP is explained in Bindings below.
Login#
When an SP wants to authenticate a Feide user, an authentication request is sent from the SP to the IdP. The message is sent by redirecting the user to the IdP web page for authentication.
1 <samlp:AuthnRequest
2 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
3 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
4 ID="_c9c029ec886798536d71de9588668f46e7d15b1869" Version="2.0"
5 IssueInstant="2009-10-26T13:01:03Z" ForceAuthn="false" IsPassive="false"
6 Destination="https://idp.feide.no/ssp/saml2/idp/SSOService.php"
7 ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
8 AssertionConsumerServiceURL="https://ow.feide.no/ssp/saml2/sp/acs.php">
9 <saml:Issuer>
10 urn:mace:feide.no:services:no.feide.openwikicore
11 </saml:Issuer>
12 <samlp:NameIDPolicy
13 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
14 AllowCreate="true"/>
15 </samlp:AuthnRequest>
Example 1: Authentication request
A typical authentication request is shown in example 1. Key elements in the message are:
Unique ID for the request. The authentication response refers to this ID.
Destination endpoint URL for this request. This information is taken from the IdP metadata that have been imported into the SAML software.
ProtocolBinding indicates how the response message is to be transported from the IdP to the SP. Bindings are briefly explained in Bindings below.
AssertionConsumerServiceURL is the destination URL for the authentication response message sent back from the IdP to the SP.
Issuer is the entityID for this service.
Upon successful authentication the browser is instructed to post the authentication response message by HTTP-post binding to the AssertionConsumerServiceURL at the SP.
1 <samlp:Response
2 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
3 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
4 ID="_a7b867d86431b76adb83afca3e99f6192957e8183d" Version="2.0"
5 IssueInstant="2009-10-26T13:04:16Z"
6 Destination="https://ow.feide.no/ssp/saml2/sp/acs.php"
7 InResponseTo="_c9c029ec886798536d71de9588668f46e7d15b1869">
8 <saml:Issuer>https://idp.feide.no</saml:Issuer>
9 <samlp:Status>
10 <samlp:StatusCode
11 Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
12 </samlp:Status>
13 <saml:Assertion>
14 CUT: Assertion part shown separately
15 </saml:Assertion>
16 </samlp:Response>
Example 2: Authentication response
A typical authentication response is shown in example 2. The Assertion part of the message is separated out and shown in example 3.
Key elements in the message are:
InResponseTo refers to the message ID in the AuthnRequest message.
Issuer is the entityID for the IdP.
The value of the StatusCode indicates whether the authentication was successful or not.
1 <saml:Assertion
2 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3 xmlns:xs="http://www.w3.org/2001/XMLSchema"
4 ID="pfx6a5dfea5-0003-da58-55b0-fd94ff968018" Version="2.0"
5 IssueInstant="2009-10-26T13:04:16Z">
6 <saml:Issuer>https://idp.feide.no</saml:Issuer>
7 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
8 CUT: Lot of signature markup
9 </ds:Signature>
10 <saml:Subject>
11 <saml:NameID
12 SPNameQualifier="urn:mace:feide.no:services:no.feide.openwikicore"
13 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
14 _508ddf0c3974b7a5951f5879e0796f97be449fcfdd
15 </saml:NameID>
16 <saml:SubjectConfirmation
17 Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
18 <saml:SubjectConfirmationData
19 NotOnOrAfter="2009-10-26T13:09:16Z"
20 Recipient="https://ow.feide.no/ssp/saml2/sp/acs.php"
21 InResponseTo="_c9c029ec886798536d71de9588668f46e7d15b1869"/>
22 </saml:SubjectConfirmation>
23 </saml:Subject>
24 <saml:Conditions
25 NotBefore="2009-10-26T13:03:46Z"
26 NotOnOrAfter="2009-10-26T13:09:16Z">
27 <saml:AudienceRestriction>
28 <saml:Audience>
29 urn:mace:feide.no:services:no.feide.openwikicore
30 </saml:Audience>
31 </saml:AudienceRestriction>
32 </saml:Conditions>
33 <saml:AuthnStatement
34 AuthnInstant="2009-10-26T13:04:16Z"
35 SessionNotOnOrAfter="2009-10-26T21:04:16Z"
36 SessionIndex="_64da5b6b8235a8f13433e1604a1e0b31c1cd1bbb7d">
37 <saml:AuthnContext>
38 <saml:AuthnContextClassRef>
39 urn:oasis:names:tc:SAML:2.0:ac:classes:Password
40 </saml:AuthnContextClassRef>
41 </saml:AuthnContext>
42 </saml:AuthnStatement>
43 <saml:AttributeStatement>
44 CUT: Lots of attribute markup shown separately
45 </saml:AttributeStatement>
46 </saml:Assertion>
Example 3: Assertion part
Key elements in the assertion part are:
The assertion is signed to prevent tampering with the message.
SessionNotOnOrAfter indicates the lifetime of this assertion. Session timing is discussed in The user’s Feide session below.
The SessionIndex is an ID for the IdP session.
The value of AuthnContextClassRef indicates how the user was authenticated. Feide supports password and multi factor authentication.
In the Assertion you will also find an AttributeStatement. The attributes transmitted to the SP are contained in the AttributeStatement. You find a description of the formatting of the attributes in SAML Assertion below.
Logout#
Feide supports logout from one single service at a time or Single Logout (SLO) from all the services in the Feide federation where the user is logged in.
A LogoutRequest message is sent to an entity to request a logout from that entity. That entity responds by sending a LogoutResponse message. The LogoutResponse indicates whether the logout was successful or not. Depending on the mode of logout the SP may send a LogoutRequest to the IdP or receive a LogoutRequest from the IdP. The SLO modes are explained in Logout SLO.
1 <samlp:LogoutRequest
2 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
3 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
4 ID="_00ec286b0a91d783747cf237b84cba133a76693b8c" Version="2.0"
5 Destination="https://idp.feide.no/ssp/saml2/idp/slo.php"
6 IssueInstant="2009-10-26T14:34:25Z">
7 <saml:Issuer>
8 urn:mace:feide.no:services:no.feide.openwikicore
9 </saml:Issuer>
10 <saml:NameID
11 Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
12 SPNameQualifier="urn:mace:feide.no:services:no.feide.openwikicore">
13 _508ddf0c3974b7a5951f5879e0796f97be449fcfdd
14 </saml:NameID>
15 <samlp:SessionIndex>
16 _64da5b6b8235a8f13433e1604a1e0b31c1cd1bbb7d
17 </samlp:SessionIndex>
18 </samlp:LogoutRequest>
Example 4: Logout request
A logout request example is shown in example 4. Key elements in the message are:
NameID is an identification of the subject (the user) of the messages and has to match the NameID in the Assertion message, here shown in example 3.
The SessionIndex is the SessionIndex from the login assertion.
1 <samlp:LogoutResponse
2 xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
3 xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
4 ID="_e9c92b6a454e084428471dc99f8dcbcc7f98a31616"
5 Version="2.0" IssueInstant="2009-10-26T14:34:26Z"
6 Destination="https://ow.feide.no/ssp/saml2/sp/slo.php"
7 InResponseTo="_00ec286b0a91d783747cf237b84cba133a76693b8c">
8 <saml:Issuer>https://idp.feide.no</saml:Issuer>
9 <samlp:Status>
10 <samlp:StatusCode
11 Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
12 </samlp:Status>
13 </samlp:LogoutResponse>
Example 5: Logout response
A LogoutResponse example is shown in example 5. Key elements in the message are:
The InResponseTo value is the ID from the LogoutRequest this is a response to.
The value StatusCode indicates whether the logout was successful or not.
Bindings#
The bindings specify how the SAML messages are transported between the SP and IdP. As specified in the SAML profile, Feide only uses the HTTP-redirect and HTTP-post bindings. This means that all SAML messages are transported through the user’s web browser, piggy-backed on the various HTTP requests and replies. This is called front-channel communication. It eliminates the hassle of establishing a direct communication path between SP and IdP.
The binding can be illustrated by the login transaction as shown in illustration 1.
The user tries to access a protected web page at the SP.
The SP SAML functionality instructs the user’s web browser (by redirect) to visit the login page at the IdP. An encoded version of the AuthnRequest is appended to the URL.
Upon successful authentication, the web browser receives a page including a hidden form control. The authentication response is encoded in this form. The browser is also instructed by a script to post this data to the SAML consumer endpoint at the SP.
The same principle is used for logout, except that logout only uses redirects.
Illustration 1: SAML Message flow during login
Signing#
For securing SAML communication, Feide relies on SSL/HTTPS security. This means that the SAML messages are encrypted in the communication channel between the user’s browser and the service endpoint and the browser and the IdP endpoint. But the SAML messages pass through the user’s web browser unencrypted. To prevent tampering with the assertion message on the user’s client computer, the Feide IdP signs the assertion message in the authentication response. The Feide IdP’s public certificate is embedded in the metadata for the IdP.
Profile#
Profiles define specific sets of rules for using SAML for a specific task. The following chapters are a summary of the login and logout profile used in Feide.
Login#
Feide is loosely based on the Interoperable SAML 2.0 profile specification. This is a summary of the specification, adapted to its usage in Feide.
The authentication request message:
Uses either the HTTP-redirect or the HTTP-POST binding. Please note that even though the HTTP-POST binding is allowed for sending authentication request messages, the use of the HTTP-redirect binding is recommended and encouraged.
Is not signed.
Must include AssertionConsumerURL.
Must not include RequestedAuthnContext.
Should, for the NameIDPolicy, set AllowCreate to true.
Should, for the NameIDPolicy, set nameid-format to transient.
The authentication response message:
Uses the HTTP-post binding.
SP must support unsolicited responses. This is to support the cases where the user bookmarks the IdP login page.
Includes the user attributes.
Attributes name format is basic. More information about attribute names in SAML Assertion.
SAML endpoints must use SSL/HTTPS.
Logout SLO#
The Feide IdP supports Single Logout (SLO). The SPs have to handle two different scenarios to properly handle SLO. Illustration 2 shows an example where one user is logged into three SPs.
When the user chooses to logout from SP1, then SP 1 initializes a logout by sending a LogoutRequest to the IdP. Then the user selects to logout from all the services. The IdP initializes logout on the rest of the SPs (SP 2 and SP 3) by sending a LogoutRequest to each of them. The SPs will perform a local logout and respond to the IdP by sending a LogoutResponse message back to the IdP. When the IdP has completed all the logouts it will respond to SP 1 by sending a LogoutResponse message to SP 1.
The user may initialize a SLO from any of the SPs. This means that any SP should be able both to send LogoutRequest messages and to respond to incoming LogoutRequest messages from the IdP.
Recommendation for Service Provider:
Should be able to initialize Single Logout from the service by sending a LogoutRequest message to the IdP.
Should be able to handle incoming LogoutRequest messages from the IdP. If it is able to initialize Single Logout, it must be able to handle incoming LogoutResponse messages.
Illustration 2: SLO message flow
Feide Identity Provider:
Handles Single Logout initiated by any of the connected Service Providers.
Interacts with the user to let the user select SLO or only logout from the IdP and the SP where logout was initialized.
The logout request message is:
Sent by either the HTTP-redirect or HTTP-POST binding. Please note that even though the HTTP-POST binding is allowed for sending authentication request messages, the use of the HTTP-redirect binding is recommended and encouraged.
The user’s Feide session#
When the user does a “fresh” login on the IdP for the first time, an IdP session is created. The user’s attributes are fetched from the home organization and are cached in the session storage.
The IdP session has a lifetime of 8 hours from the username and password is entered. During this 8-hour session the user will be able to directly access services without entering the username and password again. If the user tries to access a service after the 8-hour session has expired, a new Feide login is initiated and a new 8-hour session is created.
Illustration 3: Login session timing#
A new session is created on each SP when the SP receives the assertion from the IdP. The SP session lifetime is also set to 8 hours.
In the assertion part in the authentication response message is an AuthnStatement tag (example 6). This tag contains some attributes relevant to session timings.
1 <saml:AuthnStatement
2 AuthnInstant="2009-10-26T13:04:16Z"
3 SessionNotOnOrAfter="2009-10-26T21:04:16Z"
4 SessionIndex="_64da5b6b8235a8f13433e1604a1e0b31c1cd1bbb7d">
Example 6: Authentication statement
The SessionNotOnOrAfter attribute is a time stamp set to 8 hours after the authentication assertion was sent. The SP must adhere to this time limit and initiate a new login if the user tries to access the resource after this time has expired.
The login session can be terminated in one of three ways:
The user selects logout.
The user closes the web browser. The IdP and SP session cookies are automatically deleted.
The IdP session is automatically terminated 8 hours after the username and password was entered. The SP session is automatically terminated 8 hours after the SP received the assertion.
Metadata#
Before your SP and the Feide IdP can operate in a federation, the entities must exchange SAML Metadata. Feide operates both a test IdP and a production IdP.
The Feide test IdP metadata can be downloaded as XML from this link: https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php
Or found formatted for web on this link: https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml
And the Feide production IdP metadata can be downloaded from: https://idp.feide.no/simplesaml/saml2/idp/metadata.php
Metadata must be generated for your SP. This is usually done by the SAML library you are using. An SP metadata example is shown in example 7.
1 <?xml version="1.0"?>
2 <EntityDescriptor
3 xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
4 entityID="urn:mace:feide.no:services:no.feide.openwikicore">
5 <SPSSODescriptor
6 protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
7 <SingleLogoutService
8 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
9 Location="https://ow.feide.no/ssp/saml2/sp/slo.php"/>
10 <NameIDFormat>
11 urn:oasis:names:tc:SAML:2.0:nameid-format:transient
12 </NameIDFormat>
13 <AssertionConsumerService index="0"
14 Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
15 Location="https://ow.feide.no/ssp/saml2/sp/acs.php"/>
16 </SPSSODescriptor>
17 <ContactPerson contactType="technical">
18 <GivenName>Andreas</GivenName>
19 <SurName>Åkre Solberg</SurName>
20 <EmailAddress>andreas@uninett.no</EmailAddress>
21 </ContactPerson>
22 </EntityDescriptor>
Example 7: Service metadata
The most important metadata entries:
entityID This is a unique ID for your service. It should either be a URN or a URL.
SingleLogoutService The Location attribute is the URL where logout requests and responses are handled. If this endpoint is available, it must be able to both send LogoutRequests and handle incoming LogoutRequests.
AssertionConsumerService The Location attribute is the URL where authentication responses sent from the IdP will be posted.
If the entityID is a URL it should be a URL pointing to the metadata for the service.
An URN entityID should be a part of Feide’s URN-namespace
“urn:mace:feide.no:services:” and consist of 3 parts separated by
dot (.):
no for Norwegian service providers or the ccTLD for the country of origin of the service provider.
The subdomain name for the service provider.
A descriptive name for the service offered. The name should be unique in the service provider’s DNS namespace.
The entityID in example 7 shows a URN formatted entity id.
User attributes#
User attributes carry different pieces of information about the user, the user’s home organization and the user’s school. It may be information like name, role, school affiliations etc.
When the Feide IdP has successfully authenticated the user against the user directory at the user’s home organization, the Feide IdP will retrieve a set of attributes from the directory. After the Feide IdP has retrieved the attributes, it will process and filter the attributes before it passes them on according to the agreements between Feide and the SP.
Information model#
There are three documents describing the Feide information model:
The norEdu* Object Class Specification describing how the attributes are organized. The norEdu*-specification is based on eduPerson, eduOrg and some other LDAP schemas.
Feide requirements for primary and secondary education.
Feide requirements for higher education.
To understand the Feide information model, it is important to understand that the Feide federation has members from two parts of the Norwegian educational sector:
higher education (with universities and university colleges)
primary and secondary education
These two parts are organized differently as regards to ownership and internal structures, which affect the Feide information model.
Essential to the Feide information model is that each person is associated with one top organization (the home organization) and possibly one or more organization units. This is shown in illustration 4.
Illustration 4: All Feide users are associated with one home organization and possibly one or more organization units.
For students, employees and other persons in higher education, the home organization is the university / university college. Organization units are various faculties or departments within the top organization. There is no requirement that a person in higher education should be associated with an organization unit, and Feide puts no requirements on which attributes should be registered for organization units in higher education.
Illustration 5: A pupil must be associated with both a top organization and at least one organization unit. In this example, the top organization is Trondheim kommune (the municipality) and the organization unit is Nyborg skole (the school).
Because of different organization and owner structures in primary and secondary education, the Feide information model for primary and secondary education is different from higher education.
For pupils, teachers and other persons in primary and secondary education, the home organization is the owner of the school, in most cases the municipality/county. All the schools owned by the same municipality/county are organization units under the home organization. All persons in primary and secondary education are associated with at least one organization unit (one school). Feide puts specific requirements on which attributes should be registered for organization units in primary and secondary education. An example of how this might be is shown in illustration 5.
If the service is to do authorization based on school affiliation, it is crucial to understand how higher education and primary and secondary education are represented in Feide. The following list summarizes the various organization types:
Higher education:
Home organization: University, university college (e.g. Universitetet i Oslo)
Organization units: Various departments and faculties (e.g. Faculty of Humanities)
Organization unit requirements: Feide places no requirements on the organization units. They are optional. For schools that have them, they can contain any kind of organization unit data.
Secondary education:
Home organization: County e.g. (Rogaland fylkeskommune)
Organization units: Secondary schools (e.g. St. Svithun videregående skole)
Organization unit requirements: It is mandatory to register the users schools as organization units.
Primary education:
Home organization: Municipality (e.g. Trondheim kommune)
Organization units: Primary schools (e.g. Nyborg skole)
Organization unit requirements: It is mandatory to register the users schools as organization units.
Attribute availability#
The availability of attributes is governed by the norEdu* Object Class Specification together with the Feide requirements for primary and secondary education and higher education respectively. These documents state what information should be registered about each user and how the user directory should be organized.
The norEdu* Object Class Specification has been released in several versions. As a result of this, some organizations are using an older version of the specification and do not necessarily have all the attributes required by the latest specification.
A list of user attributes available for services is available here.
Name#
Due to the fact that not all home organizations adhere to the latest norEdu* Object Class Specification, there is today no single attribute that is guaranteed to hold the user’s name. A suggested strategy to get a name value to use in the application is as follows:
Check if the user has a displayName and use that. If not present…
Check if the user has one or several givenName attributes; select the first one and join with the first value from sn (surname) if you want to display full name. If not present…
Use the first value from cn (common name)
User id#
When it comes to selecting a user ID we have to balance between two conflicting demands – the services’ demand for a unique and persistent id and the users’ demand for anonymity and privacy.
The possible user IDs should be considered in the following order:
eduPersonTargetedID: This ID gives anonymous user authentication, but still gives the service the ability to track a particular user from login session to login session. This ID is different on different services for a particular user.
eduPersonPrincipalName: This is the “Feide ID”. This is a valid and unique user ID as long as the person is a member of an educational institution.
norEduPersonNIN: This is intended as a lifelong personal identity number. Where a key is needed to combine information from other governmental information sources, this ID can be used.
Schools#
As described in section 5.1, higher education and primary and secondary education are organized in different ways and this affects the Feide information model. To simplify, Feide can release the attribute feideSchoolList to SPs that request information about the users’ schools. feideSchoolList is a multivalued attribute with the following properties:
Contains the schools’ organization numbers, which uniquely identify the schools.
If there is a primary school registered for the user, this school is listed first.
For users in higher education, only the organization number of the home organization is listed.
Grades and subjects#
For pupils in primary and secondary education it is intended to populate the eduPersonEntitlement attribute with Grep-codes. Grep-codes can be used to express a pupil’s grade, subjects, major area etc. For further information please contact Feide.
SAML Assertion#
The attributes are transmitted from the IdP to the SP wrapped in a SAML assertion. The SAML specification only specify an attribute name-value pair relationship. It does not specify how to map a tree like information structure into a flat name-value pair message structure. This chapter will explain how Feide organizes this information in the SAML assertion.
Attribute value letter case#
User identity values like eduPersonPrincipalName are by definition case insensitive. However, Feide preserves case for attribute values and some home organizations have saved the values with both uppercase and lowercase letters. We therefore recommend doing case insensitive matching when eduPersonPrincipalName is used as a user identity key in the SP system.
Referenced objects and namespaces#
1 <saml:Attribute Name="eduPersonOrgDN:mail"
2 NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
Example 8: Attribute name
All attributes carrying information about the user’s home organization are prefixed by “eduPersonOrgDN”, and all attributes carrying information about the user’s organization units are prefixed by “eduPersonOrgUnitDN”. The prefix and the attribute name are joined with colon (:). The notation is shown in example 8.
Multivalued attributes#
The SAML assertion message snippet in example 9 shows an example where eduPersonAffiliation has multiple values. There is no particular ordering of the attribute values.
1 <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
2 <saml:AttributeValue xsi:type="xs:string">
3 employee
4 </saml:AttributeValue>
5 <saml:AttributeValue xsi:type="xs:string">
6 member
7 </saml:AttributeValue>
8 </saml:Attribute>
Example 9: Multivalued attribute
Several orgUnits#
The user may be tied to several orgUnits. The Feide IdP does some custom mapping to be able to convey this information to the service via the assertion message.
Illustration 6: Multiple org units mapping
The value for each attribute name in each orgUnit object is grouped together as a multivalued attribute in the assertion message. This mapping is illustrated in 6, and example 10 shows an example message. This mapping is done consistently, so for each attribute name in the assertion message, the first value is always from the first orgUnit object and so on. An empty value is inserted if an orgUnit object is missing this attribute.
1 <saml:Attribute Name="eduPersonOrgUnitDN:cn" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
2 <saml:AttributeValue xsi:type="xs:string">
3 Eksterne tjenester
4 </saml:AttributeValue>
5 <saml:AttributeValue xsi:type="xs:string">
6 Tjenesteavdeling
7 </saml:AttributeValue>
8 </saml:Attribute>
Example 10: Attribute from multiple OrgUnits
This mapping alters the semantic meaning of multivalued attributes in the assertion message for orgUnits. So, in the cases where the orgUnit attribute is already multivalued, this has to be encoded in a different way. The multivalued attributes are joined together with the pipe (|) symbol as a separator. Example 11 shows an example where the ou attribute has two values.
1 <saml:Attribute Name="eduPersonOrgUnitDN:ou" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
2 <saml:AttributeValue xsi:type="xs:string">
3 ET|Eksterne Tjenester
4 </saml:AttributeValue>
5 <saml:AttributeValue xsi:type="xs:string">
6 TA|Tjenestavdelingen
7 </saml:AttributeValue>
8 </saml:Attribute>
Example 11: Multivalued attribute from multiple OrgUnits
Testing#
Feide has some infrastructure to facilitate integration testing for service providers.
Test IdP to test the SP ↔ IdP communication and metadata compatibility. The test IdP metadata is found at: https://idp-test.feide.no/simplesaml/saml2/idp/metadata.php?output=xhtml
To start testing your service, it must be integrated with the Feide test IdP. This is done by exchanging metadata with this IdP.
Feide has a test user.
Organization Feide Username test Password 098asd
Feide IdP-test stores a cookie in your browser. The name of this cookie is SimpleSAMLSessionID. You can delete this cookie when you do trial and error testing, to get back to a “clean state”.
For further support, you can contact Feide support at e-mail address: support@feide.no