| Prev | Next |
Single Sign-On (SSO) with WebEA
As with Enterprise Architect, WebEA can make use of these Single Sign-On systems:
- Windows authentication with Active Directory
- OpenID
The ability to use Single Sign-On for WebEA is based on the configuration of the Enterprise Architect model itself.
Steps
Step |
Description |
See also |
|---|---|---|
|
1 |
Using Enterprise Architect, configure the model to use Single Sign-On. |
Single Sign-On (SSO) |
|
2 |
Using Enterprise Architect, confirm that the model can be accessed via Single Sign-On. |
|
|
3 |
If you intend to use OpenID, ensure that your OpenID server configuration includes the WebEA login_sso.php page as a valid redirect/callback URI. For example: http://myserver/webea/login_sso.php Or (if the OpenID provider supports wildcards): http://myserver/webea/* |
|
|
4 |
If you intend to use Windows Authentication and WebEA is deployed using IIS then configure IIS as described in the 'Configuring IIS for WebEA Windows Authentication' topic. |
Configuring IIS for WebEA Windows Authentication |
|
5 |
If you have not already done so, configure WebEA to access the model. No WebEA configuration options are required specifically for Single Sign-On (WebEA will detect that Single Sign-On is enabled in the model). |
How to configure WebEA models |
|
6 |
Login to the model via WebEA. The WebEA login screen will provide and/or Login with Windows ID buttons, allowing you to log in via Single Sign-On. 
|
Login |
Web Browser Considerations
Single Sign-On support can vary depending on the Web Browser being used to access WebEA.
WebEA's Windows Authentication makes use of the NTML authentication protocol. Web Browsers typically require some configuration to make use of NTLM authentication. For example, see:
https://www.websense.com/content/support/library/web/hosted/iseries_deploy/ntlm_firefox.aspx
As with Enterprise Architect, for OpenID support an OpenID server must be configured and accessible by your Web Browser.
The OpenID server must support the 'OpenID Connect' standard and should be able to return a unique user identifier in the 'user_info' request. This user identifier will be matched to a local model user.