Hi there, just wondering if anyone has any news on the ability to allow Single sign-ins for Intranet users, if using LDAP bridges?
Are there plans to implement this feature at all, is someone thinking of ways to achieve it? It would be nice to set up permissions on areas of the Intranets, and to have Matrix check to see if they are currently logged into the network using nbtstat or something similar to check and then checking allowed users against the returned results to make sure the username is present or not….
It's in. It works. * Matrix will accept external authentication against LDAP users.
- For limited environments: You need mod_auth_kerberos or an SSO proxy (like WebSeal). **
** And other things as well. Contact a friendly Implementation Person for more information.
Single Sign-On is exceptionally site-specific and needs a lot of discussion during the implementation phase.
[quote]It's in. It works. * Matrix will accept external authentication against LDAP users.
- For limited environments: You need mod_auth_kerberos or an SSO proxy (like WebSeal).
[right][post=“9627”]<{POST_SNAPBACK}>[/post][/right][/quote]
were using squid
[quote]were using squid
[right][post=“9628”]<{POST_SNAPBACK}>[/post][/right][/quote]
Squid can only do SMB/SPNEGO authentication outbound, AFAIK. We’d need to get mod_auth_kerberos running on your Matrix server linked to eDirectory or AD. Its very intricate and requires a lot of components working together in harmony, which is tough at the best of times.
I notice this SSO query is 2006 - has this in anyway progressed - Is it easier to do today with 3.16 or 3.18?
It is no easier nor more difficult -- Matrix supports trusted authentication via HTTP header. The method of injected that header is up to you -- you could do it with an external authenticating proxy (e.g. WebSeal or GetAccess Runtime) or via components like mod_auth_kerberos. If you can get the header injected, single sign-on configuration in Matrix is simple.
We have done kerberos SSO, and Shibboleth, though neither are out of testing yet. There are a lot of issues that make it difficult - in particular mixing different forms of authentication is difficult, although newer versions of apache (2.2) improve this a lot. Previous versions of apache either had to authenticate or not, you couldnt just not pass through the authentication tokens (for the user to then use a Matrix login). This really made kerberos unworkable if you wanted to have a Matrix fallback. Shibboleth is a much nicer system in terms of design (though still complex to set up and still with the mixed authentication issues), and is designed for cross domain SSO too. It seems to be taking off in education.
To get an SSO project to work, you need an Apache expert, a security expert, a system team with an overview of desktop and external security and authentication mechanisms, LDAP extertise, someone to compile and test a lot of code that is not necessarily supported by your Linux vendor, and a substantial amount of time.
We're about to start a production implementation of Kerberos-based SSO, but this will be used for all authentication for the entire site (as defined by the VirtualHost in Apache). Justin is right that mixing SSO and Matrix-based authentication is quite challenging. Though, Matrix should fire its own authentication if the SSO process fails, i.e. if there is no HTTP header presented during the authentication process.
Apache wont let you do that - if it requires authorization it will just give you a permission denied return code if it fails. No fallback allowed. Look at the new options in 2.2 if you want to try to do this. It would work if Matrix got to see the request...
You're right, of course. For my requirements, this is acceptable -- internal users will use the internal VirtualHost (with Kerberos SSO). External/VPN users will be routed to the VirtualHost that forces SSL but not SSO.