Saml SSO with mobile client

Question

I have many questions regarding SAML and it's implementation through Shibboleth. I've done a fair amount of research and I would like to clarify a few things. I have a mobile application that communicates with our server. An enterprise customer of ours, lets call them StackOverflow University, would like to provide SSO to our system using Shibboleth (or should I say SAML?). They have already sent us all the students email addresses and basic profile information. Using OAuth2, we know exactly how to provide SSO, however, with SAML we cannot wrap our heads around IDP, SP, AuthnRequest, metadata etc.

Our assumptions.

• IDP = StackOverflow University
• SP = Our application

Our customer has asked us for the following information

Please let me know the next step. I'll need at least the following information to configure our side: - your service provider entity ID - your service provider metadata (if you are not members of InCommon) - a list of attributes we should send you in the SAML assertion

We are not a member of InCommon.

Approach A student downloads our mobile application. They select their institution (StackOverflow University). The call is made to our server to retrieve the SSO configurations which has the necessary information for SAML.

1. The mobile client opens a webview and navigates to a particular web address. This web address will create a login screen. How do we config the request to use one of these urls below and a AuthnRequest?

<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://webauth.xxx.edu:8443/idp/profile/SAML1/SOAP/ArtifactResolution" index="1"/>
<ArtifactResolutionService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://webauth.xxx.edu:8443/idp/profile/SAML2/SOAP/ArtifactResolution" index="2"/>
<SingleSignOnService Binding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://webauth.xxx.edu/idp/profile/Shibboleth/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://webauth.xxx.edu/idp/profile/SAML2/POST/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://webauth.xxx.edu/idp/profile/SAML2/Redirect/SSO"/>
<SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://webauth.xxx.edu/idp/profile/SAML2/POST-SimpleSign/SSO"/>

2. The user enters their credentials
3. Things happen that I do not understand.
4. Some how our server receives the claims, creates a token, and the client uses that to communicate with our system.

Can someone help explain the process given the gaps in our knowledge?

Answer 1

Client side, you need a SAML stack.

This will implement all the plumbing for you. Most produce metadata. You send this to your IDP. This has the entityID etc. they are asking for.

Client side, you hook up your login screen to the stack.

You configure your stack with the IDP metadata address to get their metadata.

The user clicks login, the stack sends the AuthnRequest, the IDP display a login screen, the user authenticates, you get back a SAML token that contains the assertions (claims) that the IDP has configured to return.

Answer 2

I'm not sure if I understand the use case correctly, but I think the mobile client is not supposed to do any actual SAML processing; that happens between Service Provider (SP) and Identity Provider (IdP). Actually in a scenario like this, OpenID Connect would be much better suited. But just for explanation (in case SAML is mandatory), what has to happen in short is this:

• mobile app sends request to application, but is not logged in yet; the SP sitting in front of the application responds with a redirect to the IdP. That redirect contains a SAML authentication request.
• the mobile app has to follow that redirect, and then perform the login. Now the problem is that SAML does NOT define HOW the login happens; it could be an HTML form with username and password, or some kind of 2-factor authentication process. If it's the first one, the mobile app may just ask the user for their credentials and then post them directly, but that's kind of a hack, and will break next time the IdP changes their login form. Worse still, it means that the mobile app actually has the user's credentials, even though it really shouldn't; those should stay on the IdP. This is the whole big problem with SAML in mobile apps; how exactly the actual login is performed is undefined, and depends on the IdP.
• Once the login has somehow been successfully completed, the IdP will (in most cases) respond with an HTTP 200 and an XHTML-page with some JavaScript code. The page contains the SAML assertion, and will POST itself to the Service Provider. The reason why the assertion is not sent back in a redirect is that it is often too large to be sent in a URL query parameter.

So, the bottomline is that it is a difficult task to write a mobile client that performs a SAML login at a traditional IdP, because it means that the mobile app essentially has to mimick a web browser. This is where OpenID Connect is much better suited, as it has a different design approach. So try to use OIDC if that is possible.