Configuring Rules for Single Sign On
Configuring Single Sign-on
SSO system is configured based on the detection of administrator defined User Interface patterns. The system currently supports native Windows applications, Java applications and Web applications.
The UI Patterns are expressed with XML files associated with each application entry point. They are composed of:
-
Rules
-
Action
Complementary to the rules defined in Sofifd Console, the synchronization server manages a repository of user accounts and passwords, as well as other information generically known as as secrets. In general, the system will handle any number of secrets as well as any number of accounts for each managed systems. Anyway, each account for a managed system will have only one password.
All secrets can be used and manipulated using a scripting language fully compatible with ECMA-Script, also known as Javascript.
User interface pattern recognition
The user interface detection for Windows and Java applications is done using the the Application tag. This tag will contain one or more Component tagged elements. Each component could have many nested components. Each component could have one or more actions to perform when the user focus is at a selected component.
Next is a sample to inject the secret name “JconsolePassword” into jconsole application:
<Mazinger>
|
Patterns to be match |
|
Action you want to be executed |
.... |
Thus, when the system detects that the user is within a window that meets the XML specification and the password text box is the focus owner, Soffid will execute the script action that is bound. This one, will show the user password in a jconsole application field.
The Application The Application contains in the attribute cmdLine cmdLine a regular expression that is matched against the process command line. At the example, SSO will only match a running a program with a command line that ends with "jconsole". It won't apply to jconsole.exe or “jconsole test”.
The element element Application accepts the following attributes:
cmdLine |
Regular expression to match the command line. |
The The Component element allows the following attributes:
class |
Regular expression to validate against the kind of visual component, either a Java class or a window class. |
name |
Regular expression to match the name of the component. |
text |
Regular expression to match the content of a text component |
title |
Regular expression to match the title of a java component. |
dlgId |
Regular expression to match window ID dialog on Windows component. |
optional |
If the value |
check |
When the check attribute has the value “partial”, If you |
ref-as |
Specifies a name of a ECMA-Script variable that will refer to this component. |
The The Action element accepts the following attributes:
event |
Name of the event that will trigger the action. |
type |
Indicates the type of action. setText: script. |
text |
Text to assign, for setText actions. |
repeat |
If set to true, the action will be executed as many times as necessary. Otherwise, it will only run once per process. |
delay |
Time (in seconds) that must be elapsed before the action is executed again. |
Web interfaces pattern recognition
The detection is done using the element element WebApplication. This tag is independent of the browser used, and is based solely on the content of web document. Thus, the same rule will work both on Mozilla Firefox, Google Chrome or Internet Explorer.
<Mazinger>
|
Patterns to be match |
|
Action you want to be executed |
</Mazinger> |
Thus, when the system detects that the browser has loaded a page matching the XML specification (url, title and components), it will run the actions that have associated.
Mind that despite the actions are coded in Javascript, it is not the Browser javascript engine. Thus, you cannot use browser variables or functions.
The element element WebApplication accepts the following attributes:
url |
Regular expression to match the page address |
title |
Regular expression to match the title of the page |
content |
Regular expression to match the HTML content of the page |
The The Form element, will search in the HTML document for a form that matches the specified attributes. It can optionally contain one or more input element that must be present at the HTML document. It accepts the following attributes:
id |
Regular expression to match the ID attribute of the element |
name |
Regular expression to match the element name |
method |
Regular expression to match the form element's method attribute. |
action |
Regular expression to match the form element's action attribute. |
ref-as |
Specifies a name of a ECMA-Script variable that will refer to this form. |
optional |
A value |
The The Input element will search in the HTML document for an input element that matches the specified attributes. Input elements can be located within WebApplication or Form elements. In the first case you will find there is any input into the document. In the second case, just find type items included in the input form found.
id |
Regular expression to match the ID attribute of the element |
name |
Regular expression to match the element name |
type |
Regular expression to match the input type |
value |
Regular expression to match the input value. |
ref-as |
Specifies a name of a ECMA-Script variable that will refer to this form. |
optional |
A value |
The The Action element accepts the following attributes:
event |
Name of the event that will trigger the action. |
type |
Indicates the type of action. setText: script. |
repeat |
If set to true, the action will be executed as many times as necessary. Otherwise, it will only run once per process. |
delay |
Time (in seconds) that must be elapsed before the action is executed again. |
Configuring rules for basic / kerberos authentication
Some web pages are still using basic or kerberos authentication mechanisms. These mechanisms do not present a web page to be filled in by the user. Thus, the ESSO engine cannot detect it using the method described previously.
Instead, starting from Soffid ESSO version 3.0.0, there is a new tag to teach the ESSO which credentials to send in these cases. The rules will like the next ones:
<Mazinger>
<WebTransport WebTransport url="https://no-soffid.bubu.lab:4443/" system="OSCM"/>
<WebTransport WebTransport url="https://no-ad.bubu.lab/" system="ad" domain="AD"/>
</Mazinger>
Attribute
|
Value
|
---|---|
url | The base url to use. Include the protocol and port number when needed. Any BASIC, NTLM or Kerberos authentication requested by that server will be automatically answered with the credentials present in the password vault |
system | The ESSO will send any credential that the user has in that system. Other credentials will be ignored |
domain |
This is an optional attribute. It's required when trying to use Kerberos or NTLM authentication if the account name does not contain the domain name part. If the account contains the domain name, this attribute should not be present. |
Due to the different ways that browsers address this kind of authentication, the user interface will be displayed according to the browser settings. For instance, Edge and Internet Explorer will display a UA dialog box.