SSO with Native Mobile Applications

[avalanche333]

I currently use Shibboleth IDP 2.3 to provide SSO. This is all done via
Browser obviously.
I now have an ask to simply generate the signed/encoded SAML token so that a
native mobile (android/iphone) application can send it for SSO without the
need for browser.
Are they any options/suggestions for this?




--
View this message in context: http://shibboleth.1660669.n2.nabble.com/SSO-with-Native-Mobile-Applications-tp7603752.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

Post by avalanche333
I currently use Shibboleth IDP 2.3 to provide SSO. This is all done via
Browser obviously.
I now have an ask to simply generate the signed/encoded SAML token so that a
native mobile (android/iphone) application can send it for SSO without the
need for browser.
Are they any options/suggestions for this?

OSU has a mobile app for Androis and iOS built on the SAML ECP profile. If
you want to use SAML with mobile, that's how it's done, either that or
with an embedded browser.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Eric Goodman]

Is it bad form to hijack an old thread without changing the topic? Let me know and I'll repost in a new thread.

Post by avalanche333
I now have an ask to simply generate the signed/encoded SAML token so
that a native mobile (android/iphone) application can send it for SSO
without the need for browser.
Are they any options/suggestions for this?

OSU has a mobile app for Android and iOS built on the SAML ECP profile.
If you want to use SAML with mobile, that's how it's done, either that
or with an embedded browser.
-- Scott

Scott,

Per other threads, I presume your SAML ECP interface on your IdP:

* is using basic-auth
* is world accessible

Other than "mobile compatibility demanded it", were there any other discussions, requirements, mitigations that OSU went through before enabling that interface?

In particular I'm thinking of anything you might have done that could help users understand what apps (especially mobile ones) are "sufficiently trustworthy" to hold or proxy their credentials. (This would include things beyond technical solutions, such as education campaigns, etc).

Same question is posed for any other campuses that have implemented non-embedded-browser authentication solutions for mobile.

Thanks,

--- Eric

[Cantor, Scott]

Post by Eric Goodman
Is it bad form to hijack an old thread without changing the topic? Let me
know and I'll repost in a new thread.

If it's the same topic, doesn't matter to me.

Post by Eric Goodman
* is using basic-auth
* is world accessible

Yes, but I imagine your main issue is more with the clients than the
server. Any Web SSO system by definition is going to have a trivially
spoofable way of phishing people while relaying credentials unless you're
using certificates. Basic auth makes it a little easier but it's not all
that big a difference.

Post by Eric Goodman
Other than "mobile compatibility demanded it", were there any other
discussions, requirements, mitigations that OSU went through before
enabling that interface?

I tried to have the conversation, but nobody wanted to have it, so no.
I've tried fairly often since to have this conversation amongst
colleagues, but the security people I've interacted with just aren't
interested. It seems to be outside their scope of concern, or maybe it's
just too much of a swamp and they want to avoid it.

Post by Eric Goodman
In particular I'm thinking of anything you might have done that could
help users understand what apps (especially mobile ones) are
"sufficiently trustworthy" to hold or proxy their credentials. (This
would include things beyond technical solutions, such as education
campaigns, etc).

Not anything I was involved with, though I also raised that issue quite a
bit. If they've done that sort of user communication, I haven't seen it,
but it's possible they have.

Mobile is a house of cards. I guess it's either that house of cards or the
web's house of cards. Either way, I wouldn't blow too hard.

-- Scott

[Eric Goodman]

Post by Eric Goodman
* is using basic-auth
* is world accessible

Yes, but I imagine your main issue is more with the clients than the server.
Any Web SSO system by definition is going to have a trivially spoofable way
of phishing people while relaying credentials unless you're using certificates.
Basic auth makes it a little easier but it's not all that big a difference.

Correct. I'm more worried about the concept of "sanctioning" client logins that bypass the visible IdP login page (with its hopefully well known URL).

Mobile is a house of cards. I guess it's either that house of cards or the
web's house of cards. Either way, I wouldn't blow too hard.

Yeah, I expected that answer, but was holding my breath (pun intended) hoping that it wouldn't be. But at least I got another got Scott Cantor quote to throw around in future discussions! :)

--- Eric

[Cantor, Scott]

Post by Eric Goodman
Correct. I'm more worried about the concept of "sanctioning" client
logins that bypass the visible IdP login page (with its hopefully well
known URL).

Right. So this is where I like to point out that non-web authentication by
definition does that, so when people ask about non-web authentication, it
raises some interesting questions.

-- Scott