Crowd SSO and GMail on mobile phones

[William Caput]

We've configured our Crowd SSO. Only remaining concern is mobile phones using Gmail for our corporate mail. The google apps plug-in is configured and working in a test environment for workstations. However, I'm not able to use the Gmail app on Android or Iphone without relying on the web browser to connect to the SSO server. The only documentation I can find is from Google:

https://developers.google.com/accounts/docs/MobileApps

Is there another method of configuring SSO on mobile devices?

[Jeffrey Mealo]

Google Apps doesn't support SSO for IMAP or it's Gmail mobile apps. In both cases the client will be authenticating against Google's server, not your Crowd server.

Google still maintains a password for each account; separate from your Crowd SSO. These are the passwords that will be used for mobile access and IMAP/POP.

You can manually set these passwords via the Google Apps admin interface or Google API. However, there's not an off-the-shelf way of doing this automatically in Crowd.

Note: Unless providing your end users with the link to "Change their password" from a non-SSO Google Apps account still works, your end users won't be able to change their own 'Google' password. As you know you replaced the typical change password links with links to Crowd.

You may be able to use LDAP for your directory, connect that to Crowd and use the "GADS" (Google Apps Directory Sync) tool to sync the user passwords in a Cron job.

Link to GADS:
http://support.google.com/a/bin/answer.py?hl=en&answer=106368

P.S. If you're wondering you don't need to create the accounts in any particular order. If you have accounts in Crowd or LDAP accounts that match your Google accounts and you set up SSO everything should authenticate properly.

[JustinK]

3) If the Crowd server goes down, how do users authenticate? Crowd doesn't support clustering, so in the unlikely event we go down, what remedy is there? I don't think we could access our Google Apps engine to disable SSO login, as the request would go to Crowd to authenticate. Has this been considered?

Currently the only option I can suggest here is to have a cold failover for Crowd and have this managed by a load balancer, this is what most large enterprises do to maintain uptime of most of the Atlassian product suite atm.

Other things that need to be considered with this is:

1. Token storage should be backed by the database, otherwise all users would need to re-login if Crowd went down for a moment.

2. This isn't mentioned in the documentation but you can actually enter multiple urls into the Connection details tab for an LDAP directory so JNDI will actually try a secondary directory if the first fails.

4) When a Macintosh user needs to change their password, they are sent a link to their email. However, if the password expires, they can no longer access email to get the change password link.

I think the only option here is for the administrator to step in a manually reset the users password. Unfortunately this is going to be a problem when the same authentication system that is being used for email is also used for access to other systems.

5) In the event an employee is terminated, we typically disable their user account in active directory and forward their email to a supervisor. If the user account is disabled, does that prevent the email from forwarding?

Unfortunately I do not know, especially if you are talking about how Google treats inactive/disabled users. This would be something you would need to test, or ask on the Google Apps forums.

[VitalyA]

William,

It looks like this would be the case with any external identity provider for GMail, not only Crowd. You may want to try iPhone's native mail client, although we do not know whether it will work.

[William Caput]

There isn't much documentation on mobile and third party apps, but I've managed to get it working through trial and error (emphasis on error). A few things that are extremely concerning:

1) SSO doesn't work with POP or IMAP and numerous third party application (adwords, etc). It relys on the cached Gmail password, or you can enable two factor authentication and set a password in Gmail for these applications.This requires maintenance of two passwords defeating the security of SSO for email.

2) Secondary email accounts (service, group) redirect to crowd. This requires a domain account referencing them which is shared among users. This is a PCI violation as we've discovered. Looking to create a subdomain within GMail to bypass Crowd authentication. No luck so far. Thoughts?

3) If the Crowd server goes down, how do users authenticate? Crowd doesn't support clustering, so in the unlikely event we go down, what remedy is there? I don't think we could access our Google Apps engine to disable SSO login, as the request would go to Crowd to authenticate. Has this been considered?

4) When a Macintosh user needs to change their password, they are sent a link to their email. However, if the password expires, they can no longer access email to get the change password link.

5) In the event an employee is terminated, we typically disable their user account in active directory and forward their email to a supervisor. If the user account is disabled, does that prevent the email from forwarding? Is there a method aside from POP or IMAP to still access the account with a disabled active directory account?

If anyone has come accross these scenarios, please let me know how you addressed them. Thank you.

[William Caput]

The concern is regarding using an Iphone or Android to authenticate for GMail. Most of our users have mobile email, and they have their accounts setup to authenticate using the GMail application on the phone. By enabling SSO, the authentication mechanism changes. I've been trying to get my phone to work, but it wont. I think the problem is the application cannot redirect to Crowd, so in effect, mobile email wont work. Am I thinking this through correctly, or missing something? Thanks.

[JustinK]

It looks like the GMail mobile app just wraps a web browser, and because you can't change the default loading page for the app, it can't start the SAML dance.

If you could change the loading page of the app to be: https://mail.google.com/a/mycompany.com you would not have a problem, since this would re-drict to the Crowd server.

I am sorry, but I don't think there is anything we can do about this. Have you tried using the native mail clients on the devices instead of the apps?

[VitalyA]

William,

However, I'm not able to use the Gmail app on Android or Iphone without relying on the web browser to connect to the SSO server.

What are you trying to achieve? It is not very clear from the question.