Q. SAML Setup and Integration with Wallet

Usually Saml contains the Saml SP information (which is Safetrust Credential Manager). That means we need to send the initial request from Safetrust Credential Manager.
So for your points, we need to trust a Saml that may be generated for the other SP.

On Thu, Mar 12, 2020 at 8:50 AM jason hart <jhart@safetrust.com> wrote:
Thanks Binh.
1) With the dataflow, it seems to be missing an alternative step to "User Authentication".  A customer app could perform the authentication before they call the SWDK and pass in a SAML token that is used to replace the "user authentication" step, correct ?
2) User Authentication step
This would normally be a redirection inside the Mobile App, correct ?

On Wed, Mar 11, 2020 at 6:32 PM Binh Dao <bdao@safetrust.com> wrote:
Hi Jason,
The proposed data flow as the attached image. We use this flow to our wallet/vendor apps.
Note that we use the SAML token to convert it to safetrust token, we don't use saml token as a source of identification during the app usage.


On Thu, Mar 12, 2020 at 4:56 AM jason hart <jhart@safetrust.com> wrote:
Hi guys,
Can you please help with the following questions about the Wallet SDK and proposed SAML integration.
  Customer APP with SWDK
  Customer SAML Server
  Credential Manager
A. Confirm this is the proposed data flow :
1. Customer will use the REST API with a TOKEN to an ORGANIZATION to create a PERSON and ASSIGN A CREDENTIAL.
2. PERSON record is of the structure <name>@<domain.xx.yy>
3. ORGANIZATION record has a Customer SAML Server configuration for @<domain.xx.yy>
4. Customer APP includes SWDK.
5. Customer APP calls the Customer SAML Server and receives a SAML TOKEN from Customer server.
6. Customer APP passes the PERSON identifier and SAML TOKEN into the SWDK.
7. SWDK passes the Identifier, DeviceID and SAML Token to the Credential Manager
8. Credential Manager calls Customer SAML Server to verify the SAML Token
9. Customer SAML Server returns a SAML confirmation token.
10. Credential Manager generates session token as normal for a successful authentication with the SWDK
11. SWDK now syncs and maintains the connection with the Credential Manager until the Customer APP performs a logout or the Credential Manager logs the Device out.
12. Credential Manager POLLS the SAML Server every XX minutes to confirm that the previous SAML Token remains valid.  XX=0 disables the background check.
13. If the SAML Token is NOT valid, the Credential Manager will invalidate the session with the SWDK
14. SWDK notifies the Customer APP that the SAML token was expired by the Customer SAML Server.
Was this article helpful?

We’re sorry to hear that. Let us know how we can improve:

Thanks for your feedback! Let us know how this article helped:

Thanks for your feedback!