Daniel_Grosso | 2017-05-25 13:24:42 UTC | #1
On our organization we will be using the REST API to reproduce some of the PureCloud functionalities on the organization's Unified Front End. Since both front-end and PureCloud will integrate with an Active Directory, the intermediary step shown in the authorization tuturials does not apply. Is there a way to bypass this login screen whe using code grant or implicit grant autentication methods?
Thank u. Regards, Daniel
tim.smith | 2017-05-25 13:28:37 UTC | #2
The only way for a user to authorize a 3rd party application to act on their behalf is to authenticate with PureCloud. This can be done via the auth code or implicit OAuth flows using the PureCloud login screen or you can implement SAML if you have a SAML provider. There is no way for a user to authorize an application without first authenticating with PureCloud.
Daniel_Grosso | 2017-05-25 15:08:09 UTC | #3
Hi Tim. Thank u for ur answer. It makes sense to me that the user should be authenticated agains PureCloud because, as u said, the unified front end is performing api calls on behalf of a given user. However, when in this case, both front end and pure cloud integrate with an Active Directory so this purecloud authentication should be seamless, don't you agree? Is there a way to implicitly submit the purecloud form the current user's credentials? Furthermore, could u provide more information about PureCloud SAML integration, if possible?
Thanks again.
Best regards, Daniel Grosso
tim.smith | 2017-05-25 15:14:10 UTC | #4
Daniel_Grosso, post:3, topic:1343
Is there a way to implicitly submit the purecloud form the current user's credentials?
You can't simulate the login process, if that's what you're asking. However, that's what SAML is for. If you can configure your ADFS server can be a SAML provider, the user can authorize your PureCloud application by authenticating with ADFS and completing the SAML flow.
Relevant documentation:
Daniel_Grosso | 2017-05-25 15:15:38 UTC | #5
Thank u Tim
I'll check those resources.
Regards, Daniel
Daniel_Grosso | 2017-05-29 08:52:38 UTC | #6
Hello again Tim.
I've red the articles u've posted. I've understood the need for an external identity provider to achieve a seamless SSO authentication against PureCloud. I'm not sure yet if AD Federation Services are a suitable alternative for this client. I need to check on that first with the client's system administrator.
Given this, I would like to ask u 3 more questions, if u please.
1 - Are there other options to have an identity provider outside the AD that could validate the credentials against the AD? 2 - Regardless of the type of authentication, if AD integration is required, then PureCloud will need access to the AD server, right? Is this done trough Data Bridge Server? 3 - If for some reason I have to use client credentials authorization are there any functionalities that I may loose? Permission validation? Auditing?
Thanks in advance ;)
Regards, Daniel
tim.smith | 2017-05-30 15:43:53 UTC | #7
Are there other options to have an identity provider outside the AD that could validate the credentials against the AD?
See the resource center article About single sign-on (SSO) for the list of supported SSO providers. If there's one that your client uses that's not on the list, let me know what it is and I can bring it up with the auth service team to discuss adding it. It's not too big of a deal to add it if the provider implements SAML in a compliant manner.
Regardless of the type of authentication, if AD integration is required, then PureCloud will need access to the AD server, right? Is this done trough Data Bridge Server?
Check out the documentation for Azure AD and ADFS at the link above for configuration details.
If for some reason I have to use client credentials authorization are there any functionalities that I may loose? Permission validation? Auditing?
The only restriction on client credentials is that there is no user context. This means that when you authorize an application using the client credentials OAuth grant, your application cannot do anything that requires a user context. The most common thing that you can't do with client credentials is manipulate a voice call (pickup, disconnect, etc), though you can get/set attributes, view conversations on a queue, and use analytics. If you intend for your application/integration to be controlled by a person, client credentials is probably not a good fit for features or security purposes.
Daniel_Grosso | 2017-05-30 16:16:49 UTC | #8
Thank u for ur time, Tim.
I see that SAML is the way to go. The only thing the organization has that can provide SAML is the AD, so we have to manage that.
Best regards, Daniel
system | 2017-08-28 19:34:45 UTC | #9
This post was migrated from the old Developer Forum.
ref: 1343