NetX SAML Services

Updated June 28, 2024 21:17

NetX SAML SSO is a single sign-on authentication and trust system between NetX and a third-party SSO provider. SAML stands for Security Assertion Markup Language; NetX supports the SAML v2.0 specification. SAML allows NetX to provide a standardized mechanism for creating trust between the client's user authentication scheme and NetX.

Integrating NetX with a remote SSO system assumes the following:

That an SSO system is already deployed and functional; assisting with the setup of an SSO system is outside of the responsibility of NetX engineers.
That at least one other application has been successfully configured to use the existing SSO system; this ensures that issues with the integration are specific to NetX and not a general issue with the SSO deployment.

Supported vendors

The following are vendors that other customers have successfully integrated within the past:

Microsoft Active Directory Federated System (ADFS)
Ping One
NetIQ
Shibboleth
Okta

Quick start guide

NetX's SAML integration is enabled by entering the correct values inside the samlServices.xml configuration file. At a minimum, NetX needs the following information to be configured with an external SAML 2.0 Identity Provider (IdP):

Item	Description	Related property
A map of SAML attributes to designate user profile values in NetX	At a minimum, you must define the following in NetX: login (username) email first name last name	<saml> and <netx> name/value pairs, respectively. See example samlServices.xml file below.
The URL of the Identity Provider	This is where Users who are not already authenticated will be routed from NetX. Eg: https://adfs.netx.net/adfs/ls. In the SAML Services configuration file, this is value of the idpUrl property.	idpURL
The X.509 certificate	You must provide NetX with your public X.509 certificate that corresponds to the Identity Provider endpoint. This must be in the PEM format. This certificate file must be installed on the NetX server, and its path set in the certificateLocation property. See X.509Certificate for more details.	certificateLocation
The user level	Users that are new to NetX, that authenticate through SAML Services, will be automatically set to a specific user level. The default is consumer. If you want a different default, please set the userLevel property to another value. After specific users login, their user level can be changed manually by an Administrator-level user.	userLevel

samlServices.xml

All of the above information needs to be provided inside the main SAML configuration file, samlServices.xml. The file must be stored in the following locations:

Linux/Unix: <application root>/netx/config (e.g. /netx/<instance name>/netx/config)
Windows: <application root>\netx\config (e.g. C:\Program Files\NetXposure\netx\config)

In version 8.11+, a samlServices.xml with example values is deployed inside the above locations to assist with configuration.

Below is an example configuration:

<?xml version="1.0" encoding="UTF-8"?>
<samlServices>
    <samlService>
        <name>netx</name>
        <idpUrl>https://adfs.netx.net/adfs/ls</idpUrl>
        <certificateLocation>/netx/saml/netx/config/x509.cer</certificateLocation>
        <userLevel>consumer</userLevel>
        <attributes>
            <attribute>
                <saml>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname</saml>
                <netx>name1</netx>
            </attribute>
            <attribute>
                <saml>login</saml>
                <netx>login</netx>
            </attribute>
	    	<attribute>
                <saml>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname</saml>
                <netx>name3</netx>
            </attribute>
            <attribute>
                <saml>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress</saml>
                <netx>email</netx>
            </attribute>
            <attribute>
                <saml>http://schemas.xmlsoap.org/claims/Group</saml>
                <netx>groups</netx>
            </attribute> 
        </attributes>
        <groups>
            <group>
                <saml>Domain Users</saml>
                <netx>SSO Group</netx>
            </group>
            <group autoAdd="true">
                <netx>Approval Required</netx>
            </group>
         </groups>
    </samlService>
</samlServices>

Please understand that various SAML implementations (and vendors) provide different SAML attribute names. In the example above, these are names usually provided by Microsoft ADFS, which provides the name with the complete URI for that attribute (eg "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"). In other cases, something more simple may be provided. by your IdP. Please consult with your IdP administrator for assistance with what your particular IdP will be sending in the SAML response.

Mapping attributes

In order for NetX to properly register incoming users from SAML, NetX needs to know something about that user. At the very least, NetX needs a first and last name, an email, and a login (though you can easily use an email as the login as well). In order to obtain this information, the SAML must provide this information in the AttributeStatement block of the response. That might look like this snip of SAML:

<saml:AttributeStatement>
      <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
        <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>

The remote IdP is adding user attributes to the SAML response so that applications like NetX can understand a little bit about the incoming user. In this example, we have the following metadata:

Field	Value
uid	test
mail	test@example.com
eduPersonAffiliation	users, examplerole1

Please note that in this case, the user attributes are contained inside of the "saml:AttributeStatement" block. This is common, but there is a property for designating a different (XML) block if your SAML is formatted differently. Next, the field name is designated by the "Name" attribute of the "saml:Attribute" nodes; and the value is designed in the child node: saml:AttributeValue. However, some SAML formatting adds a "FriendlyName" attribute to the "saml:Attribute" nodes; these are often more human readable. However, NetX will only search for "Name" attributes; so ensure your SAML mapping uses the values from that field.

For example, we've seen something like this from Shibboleth:

<saml2:AttributeStatement>
	<saml2:Attribute 
		FriendlyName="mail" 
		Name="urn:oid:0.9.2342.19200300.100.1.3"
		NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
		<saml2:AttributeValue 
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xsi:type="xsd:string">test@example.com</saml2:AttributeValue>
	</saml2:Attribute>
	...
</saml2:AttributeStatement>

So in this case, you would map "urn:oid:0.9.2342.19200300.100.1.3" (and not "mail") to the NetX email field. Like this:

<attribute>
    <saml>urn:oid:0.9.2342.19200300.100.1.3</saml>
    <netx>email</netx>
</attribute>

If you are unsure, please capture a SAML response and update your configurations to match your SAML response. If there is not sufficient user attributes in your SAML response (perhaps the email is missing), please consult with your IdP administrator so that all required user attributes are provided.

Mapping groups

NetX's SAML integration provides the ability for groups to be mapped from your SSO provider to NetX's internal groups system. This can be accomplished by following the steps below:

In the samlServices.xml file, define the inbound SAML attribute with the correct value from your provider. Map this to the "groups" netx attribute. For example:
```
<attribute>
		<saml>http://schemas.xmlsoap.org/claims/Group</saml>
		<netx>groups</netx>
	</attribute>  
```
Then, map your provider's group names to their destination groups in NetX. In the example below, the ADFS group "Domain Users" will be mapped over to the NetX group "SSO Group".
```
<groups>
	 <group>
     	<saml>Domain Users</saml>
        <netx>SSO Group</netx>
     </group>
 </groups>
```

However, you can also configure your SAML Service to simply add all users to a specific group. That was illustrated in the example above; like this:

<group autoAdd="true">
                <netx>Approval Required</netx>
            </group>

For this, you can omit the "saml" designation, as there is no mapping in this scenario. To active the auto-add function, you must add the "autoAdd" attribute to the "group" node.

However, there are some legacy Directory Server (LDAP) properties that can affect this behavior, specifically these:

user.directory_auto_create_groups
user.directory_auto_add_to_group

"user.directory_auto_create_groups" defaults to "true", but if it's set to "false", then these <netx> groups will NOT be auto-created (and would then need to be created manually).

"user.directory_auto_add_to_group" will work regardless (and perhaps redundantly) to this new feature. Please be aware that this property is global and affects all LDAP and/or SAML configurations.

SaaS implementation

If you have a NetX SaaS deployment, you will need to fill out a SAML Worksheet and submit it to your Onboarding Specialist or Support so that the above information can be captured and configured in your environment. Professional Services charges may be applicable if advanced assistance is needed to help configure the integration.

Technical reference guide

NetX SAML Services

The basic concepts are:

A single NetX endpoint for all services: "/saml/*"
Each SAML service is defined in the samlServices.xml configuration file.
Each named service is then attached to that SAML endpoint. For example, if you have a named "acme" service, then that service is accessible at: "/saml/acme".
GETs are for obtaining a SAML request, and SAML responses are POSTed to the same endpoint.

SSO Workflow

The following flowchart diagrams the flow of information and the routing of the user's session through the SAML-based SSO process. The yellow boxes represent actual NetX URL endpoints. The purple and gray boxes show NetX properties (in purple, and example values in gray). Decisions are shown in green diamonds. The remote identity provider (IdP) is shown in purple; this is your remote SSO system/federation. And finally, if all works as expected, the user is either authenticated or denied for any failure in the process.

SamlServices.xml

Here's an example configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<samlServices>
    <samlService>
        <name>netx</name>
        <idpUrl>https://adfs.netx.net/adfs/ls</idpUrl>
        <certificateLocation>/netx/saml/netx/config/x509.cer</certificateLocation>
        <userLevel>consumer</userLevel>
        <attributes>
            <attribute>
                <saml>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname</saml>
                <netx>name1</netx>
            </attribute>
            <attribute>
                <saml>login</saml>
                <netx>login</netx>
            </attribute>
	    	<attribute>
                <saml>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname</saml>
                <netx>name3</netx>
            </attribute>
            <attribute>
                <saml>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress</saml>
                <netx>email</netx>
            </attribute>
            <attribute>
                <saml>http://schemas.xmlsoap.org/claims/Group</saml>
                <netx>groups</netx>
            </attribute> 
        </attributes>
        <groups>
            <group>
                <saml>Domain Users</saml>
                <netx>SSO Group</netx>
            </group>
         </groups>
    </samlService>
</samlServices>

SAML services configuration properties

Property	Description
postAuthUrl	After the user is fully authenticated with NetX (and SAML), where should they be directed too? The default is /app, but this could also be a Portal. Type: URL Example: /portals/myPortal
certificateLocation	Required: Path to the X509 certification file (public key). The certificate is loaded once; so if you change it, then you must restart the NetX instance. Type: String Example: /netx/acme/netx/config/x509.cer
base64	Whether the SAML will be base64 encoded (it should be). Warning: Only set to "false" if you know what you're doing. Type: Boolean Example: true / false
samlRequestParameter	When a SAML Response is received via HTTP POST, this is the named parameter which the service will find the SAML body. Warning: Only set this if you know what you're doing. Type: Boolean Example: true / false
certificateTagName	When a SAML Response is received via HTTP POST, this is the named SAML/XMP node for the embedded certificate. Warning: Only set this if you know what you're doing. Type: String Example: ds:X509Certificate
certificateConditionsTagName	When a SAML Response is received via HTTP POST, this is the named SAML/XMP node for the certificate conditions tag. Warning: Only set this if you know what you're doing. Type: String Example: saml2:Conditions
attributeStatementTagName	By default, NetX will attempt to find <saml2:AttributeStatement>, then <AttributeStatement>, then <saml:AttributeStatement>. If your SAML response uses some other convention, you can specify that here. Type: String Example: customNS:AttributeStatement
issuer	Where the remote IdP should redirect back to (POST). This is set to a default. Warning: Only set this if you know what you're doing. Type: URL Example: https://acme.netx.net/saml/acme
userLevel	By default, SAML users are created as consumer (2) level users. Furthermore, you can override this default by setting the user.sessionAutoRegisterLevel property to one of the integer equivalents. However, you can set the default user level per service with this parameter. Additionally, this parameter accepts either the integer equivalents, or the label-based Strings: browser, consumer, importer, producer, manager, director, or administrator. Type: String or int Example: producer
groupRequired	By default, any IdP authenticated user will enter NetX at the specified userLevel; however, you may want to filter out users that have no mapped roles/groups. Setting this property to "true" will block access to users that have no mapped roles/groups. In this case, the user is routed to the noAccessUrl value. Type: Boolean
noAccessUrl	If "groupRequired" is set to true, and the user is blocked access to NetX, then this is the URL where the user will be redirected after logging into the remote IdP. The default is present the NetX login screen (routed secondarily from /app). Type: String
attributes	Attributes allows you to map incoming SAML attributes to NetX User attributes. Type: Array
attribute	Each attribute map is contained within an attribute object, which consists of a saml (incoming) value, and a netx (outgoing) value. Basically: this equals that. Type: Object
attribute/saml	SAML attribute to map to a NetX field. These fields can be either designed with saml:Attribute, saml2:Attribute or Attribute. The name is designed int he SAML as "Name". Values can be either designed with saml:AttributeValue, saml2:saml:AttributeValue or saml:AttributeValue. Type: String
attribute/netx	NetX field to store the SAML value. Type: String
groups	This block allow you to map a specially designated SAML attribute to a NetX group (placing the user in that Group). First, above in the attributes, you would map an inbound SAML attribute to groups. Each AttributeValue will be mapped using this groups block. Type: Array
group	Type: Object
group/saml	The SAML attribute value to match. Type: String
group/netx	Then a match is found, into which group is the user made a member? Type: String
group autoAdd	Adds all users to a specific group (see Mapping groups). Type: Boolean
advertise	If set to true, the SAML Service will be displayed in the login UI for users to select when logging in. Type: Boolean
description	Used to display a description of the SAML service to an end user in the login UI if the advertise boolean is set to true (see above). Note: this is no longer supported as of NetX 9.0. Type: String
label	Used to display a label of the SAML service to an end user in the login UI if the advertise boolean is set to true (see above). Type: String
samlService	Required: All SAML services properties are contained within this object. Type: Object
name	Required: The name of the service (to be filled in by the configuring engineer, not the customer) Type: String Example: acme
idpUrl	Required: The URL to the remote Identity Provider (IdP) Type: URL

NetX user attributes (for mapping):

login
name1 (firstname)
name2
name3 (lastname)
name4
email
phone1
phone2
phone3
phone4
organization
address1
address2
city
state
zip
country

X.509 Certificate

To properly utilize your SAML Service endpoint, each configuration requires that you provide a server-side path to the corresponding X.509 certificate. You must obtain this certificate from your IdP system directly, and it must be installed on the NetX server to establish trust. Only SAML responses to each endpoint that can be validated with the specified certificate will be accepted.

NetX requires that the X.509 certificate be formatted as PEM. PEM files are X.509v3 files that contain ASCII (Base64) armored data prefixed with a "—– BEGIN …" line. If you have DER, or other certificate format, you must first convert that to PEM. It is also possible to set up the service with a bogus PEM certificate (so the service can initialize itself), test the SAML endpoint, and in the resulting error (in your browser), the raw SAML will be printed. Inside that SAML, you can find the embedded X.509 certificate. For example:

<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate>MIIC3DDDAcSgAwIBAgIQWgvEwjIZ45pGh+L3Y3Pt6jANBgkqhkiG9w0BAQsFADAqMSgwJgYDVQQDEx9BREZTIFNpZ25pbmcgLSBhZGZzcG9jLm5ldHgubmV0MB4XDTE2MTIyOTAwNDkzM1oXDTE3MTIyOTAwNDkzM1owKjEoMCYGA1UEAxMfQURGUyBTaWduaW5nIC0gYWRmc3BvYy5uZXR4Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANLtcUvtqbpT395qYjUqQmaVIULco6pPGggG+9qO/Ag1SWmlxEDJfd8GFxPg5FWVp+VGH8xYyopjOJkcQjsKDN6cmGnv+pBbQ8D6xH0Dsw0IwL++lqVKHodIdbMZ2k48iBr22up+SedknHFv2IsBSOHuhgAr7WWCGiww1ZrbIMHRNOiPBp/ng5JqrlY6BlZz3dvSMo/rmWp2HTNwf3pIo0ELXI/pmURt5Yy/Z2U7Dd9XdffWJ+z7cozAC0hJTNW8ey1iArMJ0bCCnu1G3SdK65fiFh0YP1w/Iznr+GmUj57HKFCoSwge69Jy+4AJ07zmXGlpWOy6wZF/zEp8WerBrpkCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAxPzakPkj16aCCZkOFLw6+vaTOqYv3+KuJ64awrRGC6kQulysWzfdRGrkuXI+KulZgej9IkC4/ggmnjcBw49U4j3ViM1opJjyMNYwlmEcgOGYW6W3S+F45guyDk/wtCoKe1UgnTJKQBLkDO+c7G7qcN94GPN0/GnFEfSiIcV5Am+m3Z/faGGjAmHPq44JJPfnH7GU/tQiLoJenvUUkIXJPLsCXG1OngYSB9QJt1gBcw2PRLlFjEOTAtH4ZcKRybxBU7sg3jEHvhTTjKNdgB22BHxGs9lu4s3PoGb4+XinowwhLpoWl/lGVgBOAsx6zY/miqCzASKekOtgirX4HNaS+Q==</ds:X509Certificate>
                </ds:X509Data>
            </KeyInfo>

You can extract the certificate from that block and manually format it into a PEM file, like this:

Such files can have "cer" or "pem" extensions (the extension is irrelevant).

Warning: please do NOT provide an encryption certificate (one that contains your private key for your IdP); instead, only ever provide the signing certificate (one that only contains the public key for your IdP).

SAML errors

The SAML Service system will present errors directly into the HTTP response. So if you are testing manually, you can determine various issues directly within the Web Browser. However, these messages also appear in the logs.

Error	Reason
Assertion falls outside of valid conditions (NotBefore/NotOnOrAfter)	The time embedded in the SAML falls outside of the acceptable bounds. That is, the SAML response has "not before" and "not on or after" conditions. If NetX finds the time is outside of these boundaries, this error will be thrown.
There are no nodes for ({attributeTagName})	No data (at all) could be obtained from the SAML response. Please check the SAML response and ensure that it contains the attribute, that there is an Attribute Statement block, and/or that the attributeStatementTagName corresponds to what is found in the SAML response.
There are no attributes for ({attributeTagName})	No attributes could be obtained from the SAML response, though some attribute nodes were found.. Please check the SAML response and ensure that it contains the attribute, that there is an Attribute Statement block, and/or that the attributeStatementTagName corresponds to what is found in the SAML response.
Failed to create user via mapping class	Something went wrong when trying to create a NetX user with the available SAML data.
Failed to create user via mapping class	Something went wrong when trying to create a NetX user with the available SAML data.
Exception	Something unknown occurred; the exception message will be included.
No SAML	No SAML body was received. Either the POST was blank, or the body was provided in a parameter other than "SAMLResponse".
General failure to obtain or parse SAML	Some unknown error occurred while parsing the SAML; however, the exception message will be included.
Failed to trust SAML (signature/cert)	An exception was thrown when trying to verify the signed SAML assertion using the provided X509 certificate. Either the certificate is not valid, the assertion was not signed, or it was signed incorrectly.

In the case of a simple error, NetX will present the user with the message within the standard error presentation:

However, in the case of an actual Exception, then the message will be presented in plain text, followed by a raw dump of the SAML Response:

<?xml version="1.0" encoding="UTF-8"?>
<samlServices>
	<samlService>
		<name>my name 1</name>
		<idpUrl>my url</idpUrl>
		<postAuthUrl>my url</postAuthUrl>
		<certificateLocation>my certificate</certificateLocation>
		<base64>true</base64>
		<samlRequestParameter>SamlRequest</samlRequestParameter>
		<certificateTagName>certificateTagName</certificateTagName>
		<certificateConditionsTagName>certificateConditionsTagName</certificateConditionsTagName>
		<attributeStatementTagName>attributeStatementTagName</attributeStatementTagName>
		<issuer>my issuer</issuer>
		<userLevel>consumer</userLevel>
		<attributes>
			<attribute>
				<saml>http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname</saml>
				<netx>login</netx>
			</attribute>
			<attribute>
				<saml>http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname</saml>
				<netx>username</netx>
			</attribute>
		</attributes>
		<groups>
			<group>
				<saml>My role 1</saml>
				<netx>My group 2</netx>
			</group>
			<group>
				<saml>My role 1</saml>
				<netx>My group 2</netx>
			</group>
		</groups>
	</samlService>
	<samlService>
		<name>my name 2</name>
		<idpUrl>my url</idpUrl>
		<postAuthUrl>my url</postAuthUrl>
		<certificateLocation>my certificate</certificateLocation>
		<samlRequestParameter>SamlRequest</samlRequestParameter>
		<certificateTagName>certificateTagName</certificateTagName>
		<certificateConditionsTagName>certificateConditionsTagName</certificateConditionsTagName>
		<attributeStatementTagName>attributeStatementTagName</attributeStatementTagName>
		<issuer>my issuer</issuer>
		<userLevel>administrator</userLevel>
		<attributes>
			<attribute>
				<saml>http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname</saml>
				<netx>login</netx>
			</attribute>
		</attributes>
		<groups>
			<group>
				<saml>My role 1</saml>
				<netx>My group 2</netx>
			</group>
			<group>
				<saml>My role 1</saml>
				<netx>My group 2</netx>
			</group>
		</groups>
	</samlService>
</samlServices>

Example SAML response (for reference)

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">
  <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="pfx2c5d7bde-e34e-f7d6-681e-e449f5a7f9b6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z">
    <saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
  <ds:Reference URI="#pfx2c5d7bde-e34e-f7d6-681e-e449f5a7f9b6"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>/uzflv9Nplc1S32rm+NNLptmZ5g=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>DRBUFyw8K1gPnuw0LVoZGE3Ip5Ix4CR/UMXSO2lnBn3YIRi0RYVRdzwNMZiEcfGo/3sLkK3+tc+WjjIVhWZCjVXFSFMDyVm8MQwmDUXRatY5JW8+hJ+r1paZBDdxpLwr9dlmf5Wtc7zZlt9WlFeqiNKyejdj2fZm50NPInfdDeU=</ds:SignatureValue>
<ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICajCCAdOgAwIBAgIBADANBgkqhkiG9w0BAQ0DAWBSMQswCQYDVQQGEwJ1czETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMT25lbG9naW4gSW5jMRcwFQYDVQQDDA5zcC5leGFtcGxlLmNvbTAeFw0xNDA3MTcxNDEyNTZaFw0xNTA3MTcxNDEyNTZaMFIxCzAJBgNVBAYTAnVzMRMwEQYDVQQIDApDYWxpZm9ybmlhMRUwEwYDVQQKDAxPbmVsb2dpbiBJbmMxFzAVBgNVBAMMDnNwLmV4YW1wbGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDZx+ON4IUoIWxgukTb1tOiX3bMYzYQiwWPUNMp+Fq82xoNogso2bykZG0yiJm5o8zv/sd6pGouayMgkx/2FSOdc36T0jGbCHuRSbtia0PEzNIRtmViMrt3AeoWBidRXmZsxCNLwgIV6dn2WpuE5Az0bHgpZnQxTKFek0BMKU/d8wIDAQABo1AwTjAdBgNVHQ4EFgQUGHxYqZYyX7cTxKVODVgZwSTdCnwwHwYDVR0jBBgwFoAUGHxYqZYyX7cTxKVODVgZwSTdCnwwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQ0FAAOBgQByFOl+hMFICbd3DJfnp2Rgd/dqttsZG/tyhILWvErbio/DEe98mXpowhTkC04ENprOyXi7ZbUqiicF89uAGyt1oqgTUCD1VsLahqIcmrzgumNyTwLGWo17WDAa1/usDhetWAMhgzF/Cnf5ek0nK00m0YZGyc4LzgD0CROMASTWNg==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>
    <saml:Subject>
      <saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData NotOnOrAfter="2024-01-18T06:21:48Z" Recipient="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2024-01-18T06:21:48Z">
      <saml:AudienceRestriction>
        <saml:Audience>http://sp.example.com/demo1/metadata.php</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
      </saml:Attribute>
      <saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
        <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
      </saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>

Frequently asked questions

How do I control what the usernames of my users will be?

In the SAML Services configuration file, you can map the username you want from your SAML IdP to the "login" field in NetX (in this context, "login" and "username" refer to the same thing). Like this:

<?xml version="1.0" encoding="UTF-8"?>
<samlServices>
    <samlService>
        ...
        <attributes>
            <attribute>
                <saml>http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress</saml>
                <netx>login</netx>
            </attribute>
...

In this example, the incoming "emailAddress" value provided by your SAML IdP is used for the NetX "login" (or username).

It is important to understand that NetX can only obtain values for fields sent by your IdP. You may need to configure your IdP to provide more fields if you intend to use them within NetX.

What happens if I create an internal NetX account, and then later via a SAML Services configuration, that same login authenticates via SAML?

In this case, the original internal NetX account will be updated to reflect that this account is now associated with a remote SAML IdP. That is, this will now reflect that the account is controlled remotely (via SAML).

The original NetX password may be overwritten, and if configured, other aspects of the account may be changed automatically by the SAML configuration (groups, user fields, etc). Because user level is determined at the time that accounts are created, past user levels from the original internal NetX account settings will generally be retained.

Supported vendors

Quick start guide

samlServices.xml

Mapping attributes

Mapping groups

SaaS implementation

Technical reference guide

NetX SAML Services

SSO Workflow

SamlServices.xml

SAML services configuration properties

NetX user attributes (for mapping):

X.509 Certificate

SAML errors

Example SAML response (for reference)

Frequently asked questions

How do I control what the usernames of my users will be?

What happens if I create an internal NetX account, and then later via a SAML Services configuration, that same login authenticates via SAML?

Articles in this section