Configuring
SamlSAML
Any required fields will be displayed in red letting you know they must be completed before you can save.
Info | ||
---|---|---|
| ||
The fields have multiple states which are reflected by the color they are highlighted with.
|
The Code field is field is what the user profile will match against when adding users to the new login source. However, only one login source code can be activated at a time. Since OPS-COM can support a system where some users require SSO and some do not, there can be multiple login sources. For example, If no SSO is required the login source for each user would be OPSCOM. If you use SAML then the Login Source could be called SAML, if you use LDAP the login source could be names LDAP. The source name is up to the Identity Provider except for OPSCOM. For more information about configuring Login Sources refer to this wiki article.
Service Provider Fields
The Unique Identifier is is the ID of the external SAML system that comes from the provider. You, the Identity Provider provide it.
The Entity ID for Service Provider is the name that our system communicates with the your SAML system for example. OPS-COM provides that. It also becomes part of the URL for the user portal
The x509 certificate can be generated and added to the service provider.
Identity Provider Fields
These fields come from the system you are working with such as SAML when communicating with ops-com. For example, SAML should display its metadata under Federation → Show Metadata.
Once the settings have been completed and saved you will have access to the MetaData, Synchronization and Translations tab.
Metadata
The Metadata tab provides the XML that would be provided to the service provider
Sample XML File
The following is an example of a response from an external system to OPS-COM. In this case, it is a SimpleSAMLPhp service set up as the identity provider. At the bottom are several attributes within an saml:AttributeStatement tag. These are required for our system to match to a user within our system. The one field that matters in this attribute section is what is being used as the permanently unique identifier for a user. In this case it is "uid". Since "uid" is being sent back, then the setup for Identity Provider Fields should have "uid" as the Unique ID Field. If the unique ID is something else such as SAMaccountName, then that should be used for UniqueID.
Code Block | ||
---|---|---|
| ||
<?xml version="1.0"?> <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_aa1963115aa6490e728c7376f4c8849813bbb..."> ... <saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_9efd79bf6425983ee9176f3d33a99d1a9176180..."> ... <saml:Subject> <saml:NameID SPNameQualifier="MinionOpsComStaff" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_7a426e0be71f14c1f349db00d7d543b6f7dcb52baa</saml:NameID> <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData NotOnOrAfter="2021-08-24T16:00:41Z" Recipient="https://minion-3.dev.parkadmin.com/auth/saml2/MinionOpsComStaff/acs" InResponseTo="ONELOGIN_bb8a09203c888cf59af4c621a71cfa8f7559c016"/> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore="2021-08-24T15:55:11Z" NotOnOrAfter="2021-08-24T16:00:41Z"> <saml:AudienceRestriction> <saml:Audience>MinionOpsComStaff</saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant="2021-08-24T15:34:46Z" SessionNotOnOrAfter="2021-08-24T23:34:46Z" SessionIndex="_a7a68666092117d24aab8adecf1b0830622855b85..."> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</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">6ddf4027-3397-4e45-8628-0189f60fe91e</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="full name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">Sarah Knowles</saml:AttributeValue> </saml:Attribute> <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:AttributeValue xsi:type="xs:string">sknowles@tomahawk.ca</saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> </samlp:Response> |
Translations
Translations can be used to change the text displayed on your login button from the user side. We can create as many different translations as we have available on our system. For this example, we have English and French.
Synchronization
The synchronization tab allows you to create users in OPS-COM when they login from SAML that do not already exist by mapping your user attributes to our system. This also lets you update existing users information in the system. In this example, any field that is mapped and has a value from your SSO side should get updated to the value from SAML.
To begin, ensure that you enable Auto Create/Update User. Keep in mind that these are sample values from our test system and your SAML system may differ.
After you have supplied the information in each field you can click Save Changes and your users will begin to be created/updated. If any of the fields supplied by you are incorrect then the information will be blank when the user logs in or it will stay the same if the user already existed.
Related Pages
Filter by label (Content by label) | ||||||||
---|---|---|---|---|---|---|---|---|
|
Show if | ||
---|---|---|
| ||
No special notes. If you feel any should be added, please add them here. |