Single Sign On allows you to retain your Rock login in a Subsplash app and web tools, this means users only have to remember one set of credentials for all of your tools but also gives you full control over the login experience for your users on the Subsplash platform whether it be in the app, giving, messaging, etc.
Out of the box, Subsplash offers Email (Subsplash account), Google, and Apple as login methods to create a Profile. Enabling SSO will disable those to force your Rock login.
SSO is not required to use the plugin, only a feature of it, and can be enabled at any time after the initial setup of the plugin.
Personalized App Content
A major benefit of integrating your Rock login is the ability to personalize content to users who are logged in or not.
Once a user logs into the app, that authorization gets passed everywhere they go, and even if the user is taken from the app out to the mobile browser.
Push Notifications
Now that you know someone is logged in, send them or a group a personalized push notification.
Groups & Messaging
If using Subsplash Groups & Messaging you can sync Groups and group membership of People between Rock and Subsplash. This allows you to take advantage of Messaging in your Subsplash app and web.
Rock Web Pages
The simplest approach to do this is by using Rock web pages in your app. Once logged in the user could open a connect card in Rock and have the form auto-filled with their details automatically, a profile page could be displayed in the app that allows them to edit their household and personal information, plus more.
Custom App Feeds
A more advanced approach to personalized content is with custom feeds. In the plugin > Content and/or Custom Web Services you can set up feeds to plugin into your app that come from Rock, allowing you to use your choice of lava or security roles to show/hide items to certain users and segments.
Custom Profile Pages
When you opt for SSO, a custom profile page is often a great pairing. This would be a web page you build in Rock but give to us to replace the default profile page coming from Subsplash. This lets your users see their profile/account directly in Rock and change information that otherwise wouldn't be connected to Subsplash.
There are some requirements for this page to comply to app store polices. We highly recommend creating a new site for these dedicated app pages that way you have better control between the pages on your website and in the app.
Navigation
This should be a very simple page with no header/footer that allows navigation to other pages on your site, except for ones directly related to the profile and in the contents of the page.
Logout
Users will need to be able to log out from their account. The app needs a native command to do so and can be dispatched from a deep link. Add a button to your site with the following URL to add your log out functionality:
subsplash://sap/eyJoYW5kbGVyIjogImFwcFVzZXIiLCAiY29tbWFuZCI6ICJsb2dPdXQifQ==
Account Deletion
App stores require the ability for a user to initiate account deletion if they are logged in. Without this ability the app is at risk for removal from the store and will not be allowed any updates.
There are several paths do doing this, we recommend following Apples policy guidelines.
Custom Profile Header
A profile header is whats displayed at the top of Subsplash apps where you see initials or a profile picture while logged in. Out of the box this is supplied by the Subsplash Profile but similar to a custom profile, you can supply us an endpoint for a custom profile header.
This will need to be an endpoint that returns a JSON object rather than a web view. And can be configured in the plugin > Custom Web Services > Create a new webhook:
{
{% if CurrentPerson %}"title": "{{ CurrentPerson.FullName }}",{% endif %}
"subtitle": "{% if CurrentPerson %}{{ CurrentPerson.NickName | Slice:0,1 }}{{ CurrentPerson.LastName | Slice:0,1 }}{% endif %}",
{% if CurrentPerson %}"image":"{{ 'global' | Attribute:'PublicApplicationRoot' | ReplaceLast:'/','' }}{{ CurrentPerson.PhotoUrl }}",{% endif %}
"actions": [
{
"handler": "browser",
"style": "internal",
"contentUrl": "{{ 'Global' | Attribute:'PublicApplicationRoot' }}myaccount",
"authProviderId": "{{authProviderId}}"
}
]
}
Once this is done, coordinate with us so we can set this endpoint as the custom profile header.
Advanced Configuration Options
Bypass the permissions page
Rock’s default OIDC integration has a requirement to review and manually click "Yes" on the "Give Permission" page during the authentication process.
Sometimes Subsplash clients wish to bypass this in Rock which can be done by adding an HTML Content block to the /Auth/Authorize page. The easiest way to do this (since loading the page requires specific parameters) is to just pull it up in the Toolbox -> CMS Configuration -> Pages menu. The Give Permission page can be found under Internal Homepage -> Admin Tools -> Security -> Give Permission hierarchy in the pages menu:
In the Blocks From Page section for the Main Zone a new HTML Content block can be added with the following HTML:
<style>
div.authorize {
display:none;
}
</style>
<script type="text/javascript">
$(document).ready(function() {
window.location.href = $('div.authorize').find('div.actions>a.btn-primary').attr('href');
});
</script>
Redirecting . . .
The Redirecting . . . text content can be customized to match your organization's branding and design.
Frequently Asked Questions
Why am I seeing "Object moved to here” message when you try to login?
Rock 17.1 introduced some changes related to OIDC, which is what we use for SSO. You need to make sure a Login page is set for your External Site handling the OIDC routes like /Auth/Authorize.
How long does a user stay logged into the mobile app from Rock?
The short answer is two weeks if the app has not been used within that timeframe.By default, Rock has three different OIDC tokens used in the lifetime of a user’s login. For developer’s reference, this is Rock Core, so it is not configurable.
The first is the Identity Token, which is used during the authentication handshake. Once the user clicks that they want to log in and enters their credentials, that user must finish the entire login process within 20 minutes.
The second is the Access Token. When the access token expires, the application can use the refresh token to obtain a new access token. It can do this behind the scenes, and without the user’s involvement so that it is a seamless process for the user. This token is good for 1 hour.
Lastly, the Refresh Token. This is used to re-authenticate a session to get a new Access token. By default, this token is good for 2 weeks.
I can get to the login screen on the mobile app, but once clicked to login - then it fails.
In Rock, make sure your “Public Application Root - Global Attribute” is correct, and that it starts with “https”.You can find this Global Attribute if you go to Admin Tools > General Settings > Global Attributes > Public Application Root.
Make sure the Public Application Root value starts with “https://”, and that https is enabled. If you just made this change, make sure to restart Rock before trying again.