Known issues - SSO
- Former user (Deleted)
- Former user (Deleted)
- Arto Vainiolehto
- Former user (Deleted)
Long Certificates Require Manual Installation in Linux Version
When a long certificate is set in suffix.pfx, whose base64 encoded string is longer than about 4000 characters, it causes the installation procedure to fail. This is due to an issue with OpenLDAP ldapmodify tool, which is unable to read lines longer than 4096 characters long and sso installation script writes the base64 encoded certificate in one line in secrets.ldif. To address this issue, a tool ldiffold.sh is included with sso 7.1.0 linux version, which folds given ldif file so that it no longer contains extra long line. It can be run as follows:
cd /usr/local/ubisecure/ubilogin-sso/ubilogin/ldap ../../tools/linux-x64/ldiffold.sh < secrets.ldif > secrets.ldif.tmp mv -f secrets.ldif.tmp secrets.ldif
Ubilogin Ticket Protocol Attribute Size Limits
The Ubilogin Ticket Protocol uses the HTTP GET method to send authentication and authorization information from UAS to Web Agents. The HTTP GET method has a size limit. The size limit affects the amount of information it is possible to successfully send from UAS to Web Agents. The SAML 2.0 protocol resolves this size limit by using the HTTP POST method to send information from UAS to Web Agents.
Ubilogin SAML Service Providers use SAML 2.0 protocol.
Ubisecure SSO, SAML 2.0 and High Availability
When installing Ubisecure SSO in High Availability mode, there are some restrictions due to some protocol requirements when using SAML 2.0. Please refer to the Ubisecure Clustering document for more information.
Ubisecure SSO Management Filters
- Filter does not show correct results when filter expression is short and scandinavian characters are included
- Filter does not accept incorrect filter expressions
Tomcat Log Unnecessary Severe Warning
The following error may appear in the tomcat application server log:
SEVERE: Servlet.service() for servlet[com.ubisecure.ubilogin.sso.ui.
servlet.ReturnServlet] in context with path [/uas] threw exceptionÂ
com.ubisecure.ubilogin.sso.ui.conversation.ConversationLostException
This error is not severe and may simply indicate a user has twice selected the same action (by double clicking or back button use). The log message will be corrected in a future release.
SAML Entity ID Length
Exceptionally long SAML Entity IDs (greater than 64 chars) are not supported when using Metadata Updater.
Custom CSS with Relative Paths
The url path of ubilogin.css stylesheet file has changed in SSO 7.0.0 to /template/<template_name>/style.css. In case a custom css file with relative paths to images etc has been used, it's required to check that the relative paths work after upgrading.
Disabled Users Are Able to Login when Federated with User Driven Federation
Currently the user account status in the local user directory is checked only during the initial authentication before the mapping is stored in the Federation Table. If user decides to accept the storing, account statuses are not checked for subsequent federations. This means that any user, that have been disabled in the local directory after they authenticated for User Driven Federation, can successfully login when they are federating with their remote account. This can be prevented by configuring the applications Authorization Policy so that it ensures the user is authorized only if the account is enabled. The procedure is described in UDF documentation page.
8.2.19 and 8.2.24 only: Access blocked to SSO with HTTP-POST for users that use Chrome
SSO blocks all POST requests sent using Chrome browser, that originate from a website, whose second level domain name differs from SSO's. The workaround for this is to comment out the <filter-mapping> having <filter-name> org.apache.catalina.filters.CorsFilter#disabled in file ubilogin-sso/ubilogin/webapps/uas/WEB-INF/web.xml.Â
<!-- THESE LINES ARE COMMENTED OUT<filter-mapping>Â Â Â Â <filter-name>org.apache.catalina.filters.CorsFilter#disabled</filter-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.conversation.logout.UbiloginLogoutConversationServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.saml2.trace.TraceServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.InfoServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.saml2.SessionRelayServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.v0.MainServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.conversation.authn.AuthnConversationServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.saml2.SingleSignOnServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.saml2.ServiceProviderServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.DiscoveryResponseServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.ReturnServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.LandingPageServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.wsf.PassiveRequestorServlet</servlet-name>Â Â Â Â <servlet-name>SSO_ECP</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.oauth2.AuthorizationServlet</servlet-name>Â Â Â Â <servlet-name>com.ubisecure.ubilogin.sso.ui.servlet.tupas.TupasIdentificationServlet</servlet-name>Â Â Â Â <servlet-name>servlet.saml2.NamesServlet</servlet-name></filter-mapping>--> |
After editing the file you must run ubilogin-sso/ubilogin/config/tomcat/update.[sh|cmd]
ForceAuthn authentications may fail if user has existing session
SSO may deny an authentication request with "Access Denied" if the request has ForceAuthn flag set and the user has an existing authentication session open already. We have a development ticket open for this: IDS-947.