Entitlement: Preconditions for connecting with Purple
Purple Manager
In this article, you get an overview of all the necessary information, that is needed by Sprylab, to connect your external Entitlement System with Purple. As soon as we have received all your input, we will do the steps needed to make your external Entitlement System work with Purple. If you are in doubt about any point in the list, get in touch with your Project Manager.
- Description of access logic
- What types of access are needed?
- Is it a Netflix model?
- Are contents unlocked on a publication date- / publication- / single content-basis?
- Type of API?
- REST-API or OAuth 2.0 / OpenID SSO
- SAML2 is not supported
- Documentation of interfaces
- For custom REST APIs:
- description and examples for all
- request and response parameters
- status codes
- response bodies
- For OAuth 2.0 / OpenID:
- Is provider auto-configuration supported?
- If not: description of all endpoints, request and response parameters, status codes and response bodies
- Any other individual logic (limitations of login counts, login via deep links etc)
- All of the requirements from the estimation phase
- Prepare and provide information on the test environment
- For OAuth 2.0 / OpenID:
- URLs of endpoints
- Client ID / Secrets
- For REST-APIs:
- URLs of endpoints
- Credentials, e.g. Basic Auth, Client Certificates or API Keys (if needed)
- Test users for all possible combinations of access
- Examples:
- user with access
- user without access (or expired access)
- user with an expired subscription but who should still have access to past issues
- user with access to specific contents only (ie. certain publications)
We can only integrate with external systems when certain performance thresholds are met. Our systems have strict limits for requests to external systems.
- Any request taking longer than 3s will be cancelled.
- Furthermore our systems will automatically disable an integration, if more than 50% of all requests within a timeframe are slower than 2s. It will stay disabled until requests are faster again.
We reserve the right to adjust these limits in case we notice negative impact on our systems and/or other customers.
We strongly recommend that the refresh tokens used for OAuth 2.0-based entitlements are usable more than once. This is needed to avoid unexpected logouts due to network problems (slow responses, interruptions etc) when the refresh flow fails to return the new refresh token to the client but internally invalidated the used token. Any further use of the now invalidated token will lead to a automatic logout for the enduser.
It is best practice, that the test users remain stable and do not expire. This is important for later tests!
We also offer our custom interface: Purple Standard Entitlement Interface