The messaging around DocuSign's upcoming authentication changes has been a bit confusing, especially when it comes to SOAP integrations. https://www.docusign.com/blog/developers/docusign-api-basic-user-password-authentication-retirement is the most recent announcement. SOAP integrations do use Basic Authentication, which is reason to think they will be impacted by this. But the article explicitly mentions the "X-DocuSign-Authentication" header, which SOAP integrations don't use. But since the SOAP api only supports basic authentication (right?), I would think they would clearly say that the SOAP api is no longer supported if that's what they meant. This recent article distinguishes between 2 different types of SOAP authentication, so is the announcement about the new method now being the only supported one?
Can I continue to use the SOAP api using App password authentication beyond October 2022?
thanks for the feedback! I'll pass your feedback along to see if we can clarify it to state what we mean by basic authentication. This announcement may be more relevant to your use-case.
If you are using an App Password (and not your DocuSign account password which you use to login to the Web UI) you will be fine to continue using it.
Related
Setting up a simple out-of-the-box ASP.NET Core MVC app in Visual Studio 2019 with authentication enabled against an Azure Active Directory will result in implicit OAuth2 flow while using OpenID-Connect.
This is illustrated here.
I just tested this and I did not have to deal with a client secret which would be mandatory for authorization code flow, so I presume above is true.
On the other hand in the documentation the use of the implicit flow is discouraged:
The implicit grant presents more risks than other grants, [...] If you
are developing a Web application that includes a backend, and
consuming an API from its backend code, the implicit flow is also not
a good fit.
To further confuse things, there is this documentation where it is stated that web apps are using the authorisation code flow:
The OAuth 2.0 authorization code flow is described in section 4.1 of
the OAuth 2.0 specification. It's used to perform authentication and
authorization in the majority of app types, including web apps and
natively installed apps.
The questions that arise are
If the implicit flow is considered a bad choice, why is it used by the ASP.NET Core MVC middleware?
Can I change the behaviour?
If yes, where and how would I be able to obtain the client secret from Azure AD's app registration?
Your observations are, unfortunatelly valid.
The samples provided use implicit flow. I would guess for simplicity. This can be seen from the configuration script for the latest sample.
All the statements regarding implicit flow are correct. Including the one from the comment.
However, we have to pay attention, that the default scaffolding of ASP.NET Core project that uses OpenID Connect, actually only performs authentication and not authorization. It also does not perform a calls to external APIs. In that sense, the implicit flow is used to only obtain an id_token, but not access_token. The former contains user profile information and does not pose security risk. Whereas the latter contains authorization data for accessing specific resource. So the id_token itself does not impose a security risk when leaked. Yes it imposes data leak if leaked, but not a security one.
There is more complete sample here. Which uses ob-behalf-of flow to get an access_token to call external service. It is still not the full authorization code grand flow, but the on-behalf-of flow. The latter is even more secure.
Generally speaking OpenIDConnect implementation in .NET Core does have implementation for handling authorization code, which can be seen from the AuthorizationCodeRecieved event. Which can be used when constructing OpenIdConnectOptions object by defining the OpenIDConnectEvents property.
Frankly, to ask why project scaffolds are so designed will not bring a lot of attention, neither will it change it something. I am pretty sure the older implementations (.net 4.5 or so) were using AuthZ Code by default. Not sure why this has changed - probably to lower the friction of implementation and understanding of samples ....
But hey, IMO using Authorization Code grand to just get an ID token is a bit of an overkill, isn't it?
Addressing the comments
1) Agree it is a mess. Authorize attribute does nothing but checking for authenticated user. It may also be configured to check for a specific role. But even then, that role will be extracted from the id_token. Because you do not have access_token in case of a web app. My point is, thet when you deal with a simple web app (front end, backend - Controllers or ASPX pages) you only deal with id_tokens and no access tokens. In that context having implicit flow significantly reduces the code complexity.
The documentation is open sourced on GitHub and any responsible programmer has the freedom (and is more then welcome) to suggest improvements or indicate problems. While StackOverflow is for technical questions and answers, not complaints about software documentation.
I have a naive question.
I am looking for some web application that implements Authentication and Authorization mechanism using api keys.
Example Case: Users authenticate themselves using an api key (apikey generation
mechanism is either GOOGLE or any other free service). The logic identify the user along
with the provided apikey and release resource access delegation accordingly]
For me the optimal case is to use Grails framework with oracle database.
Is there any web application for that?, otherwise how would I follow step by step to accomplish it?
I would do a search on the Grails plugin site for oauth plugins:
http://plugins.grails.org/
Look at what they offer, and maybe look at the code to see how you can extend them to get what you want.
I would also take a look at the Spring Security Rest plugin.
It really depends on authentication methods that you're using. I suppose in order to secure REST APIs, you can probably write a filter/interceptor to check against any third party auth that you desire. I reckon that you're probably having the idea of using JWT authentication for this, right?
I'm working on a submission for a conference. I'd like to integrate DocuSign with Alfresco's Angular based developer framework and specifically the Alfresco Content App.
In order to keep things simple, I'd like to think about workflows that could be done 100% from the browser without any backend code of my own.
I suspect I could create a "Sign this document now" type action for any document found in the Alfresco UI. That could initiate an OAuth flow that would not require any backend services of my own.
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Are there other use cases I can implement in an SPA without adding backend services of my own? Things like, sending a doc out to be signed by one or more people? Or embedding a signing experience in the Angular UI?
I have seen the following series on the DocuSign blog:
https://www.docusign.com/blog/dsdev-building-single-page-applications-with-docusign-and-cors-part-1/
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
I also have not found any place online where I can reach out to a developer evangelist from DocuSign to discuss my options. I believe DocuSign developers monitor SO, so figured this was the next best thing.
Great question. Browsers implement the Same Origin Policy. So, as I wrote in the blog series (see all three of my posts listed below), you will need a CORS gateway to make API calls from your Angular program running in the browser itself to the DocuSign system.
The good news is that creating a private CORS gateway isn't hard. See part 2 of the series:
Part 1. Introduction
Part 2. Building a private CORS gateway
Part 3. An example React SPA
Authentication
Your app will need an access token when it makes API calls to DocuSign. There are multiple techniques available to give your app the access token it needs:
Your app can, by itself, authenticate the user with DocuSign. In this case, because of the security issues--as you mentioned in your question--you do not use the OAuth Authorization Code Grant flow. Instead, you use the OAuth Implict Grant flow, which is designed for this use case. This flow is demonstrated in part 3 of the blog series.
You can implement the OAuth Authorization Code Grant flow in your server, and then create a private API between your server and your browser app to obtain the access token.
A private API
As an alternative to using CORS, you can just implement your own private versions of the DocuSign API methods on your server. Then your browser app would send a private_send_envelope request to your server. Your server would manage the access token, send the request to DocuSign, and relay the response back to your browser app.
This pattern is the same as your question about implementing a backend service. It will work fine but is not as elegant as implementing everything within your browser app. Depending on your immediate and future API needs by your SPA, this might be a good idea or not.
CORS support is the key
Until DocuSign has CORS support you'll need to build something on the backend. Either a CORS gateway (which only involves configuration, not software) or a private API gateway.
Please ask your DocuSign sales or technical contact to add your information to the internal DocuSign proposal for CORS support, PORTFOLIO-1100. This will help raise the priority of CORS support. Thanks.
Specific answers
Regarding:
I think I would need to put my integrator key into the SPA. This would then be visible to anyone using the app. From reading through docs, I'm unclear if it is OK to "leak" this key?
Answer: It is okay to add your integrator key (IK) to your browser app if and only if the IK is set for Implicit Grant usage (check the "Mobile App" checkbox on the IK's property sheet).
Having read through that and also the REST API documentation, I'm still unclear if it is even possible to implement something like this without any support from my own backend service.
Answer: at this time you will either need to implement a private CORS gateway or implement backend software.
At the moment we are building a web shop as a SPA application. All the SKU information is provided by a Web Api 2 service.
Of course the web shop is publicly available to every visitor, and currently there is only one user who can log in to manage the web shop: the administrator.
For the administrator we built in the basic authentication with the bearer token, as a lot of samples on the internet shows us, but now we need every user to log in before they can see any product. Not really what we have in mind for a web shop ;-)
What we would like to implement is that our Web Api is not available to the world but only for our SPA application. Every blog post or tutorial on authorization seems to assume that there is always a user that needs to log in, in our case there is only one user: the administrator.
The AllowAnonymous attribute makes specific API calls available to the world again, so that's also a dead end.
Basically it comes down to preventing any other apps (web or mobile) to fetch the data from our Web Api.
What would be the best and most secure approach to secure our Web Api without having the anonymous visitors of our web shop to log in?
Solution for now: Altough I'm not 100% happy with this solution, it will work for now. We implemented the OAuth Implicit flow with CORS enabled for specific domain.
You should take a look at the OAuth 2.0 client credentials flow. The client in OAuth speak is the application and not the user using the application. This way you can make sure only your SPA app can access the backend API.
The parts that only should allow access to the administrator, you can decorate with the [Authorize(roles = administrator)] attribute, which prevents any other roles from having access.
I think Json Web Token could help you with this. This article has more information about using Json Web Token for granular authorization of your web api.
OAuth 2.0 is inherently insecure, and solely relies upon SSL. It has no encryption, and most of the latest web api gurus are suggesting that it's dead. This again is relative to what you need the security for. If it's for a social SPA where the data isn't financial or medical, for example, and good enough SSL security is ok, then perhaps OpenID or OAuth2 is suitable.
A much better solution is to implement Identity 2.0 for the Web API authentication flow, and then utilize something like Hawk Protocol for HTTP MAC implementation. Check this out : https://github.com/webapibook/hawknet for an example.
For OAuth2 framework and a extensible solution, check out Thinktecture.IdentityServer3 on GitHub
For a lightweight .net 4.5 Web API Tokenization solution, check out Thinktecture.IdentityServer2 on GitHub.
Hope it helps.
I have seen in the some articles, It is said that OpenID Connect would replace SAML as the dominant protocol for SSO. I am not sure how openID connect would handle the session management capabilities with different service providers and how it could be used to implement single logout? Currently, Are there are IDM servers (open source or commercial) that supports OpenID connect as a SSO IDP (as replacement for SAML2 SSO IDP)?
PingFederate [disclaimer: as it says in my name, I work for PingIdentity] built OIDC into the product in April 2013 - version 7.0. Additionally, we've supported OpenID since December 2010 via an integration kit.
That said, "SLO" (Single Logout) under OIDC is a whole new ballgame. I'd suggest having a read through the Session Management portion of the OID Spec. The gist of it is that SLO is done completely different than the way most SAML systems implemented it, and it's very user-centric, rather than OP or RP specific.
One last thing... While it's possible that OIDC will replace SAML eventually, I'd just like to point out that we've finally got a serious snowball effect going with SAML. OIDC isn't yet final, and it's going to take time to migrate to. Will the focus shift? Quite possible. But it won't happen this year, or next, and most likely not for a couple more after that. If you're looking at products that are bleeding edge that support OIDC, fair enough... But if you're actually wanting to implement, the opportunities are few and far between. There just aren't a lot of RPs out there yet - primarily because the spec isn't "final".
I should also mention that some of our competitors, like Gluu, Okta, IBM, and Layer7 have shown support for OIDC (by competing in interop testing), but I can't speak to the extent of their support in current products.
OpenAM seems to support it from release 11. wikis.forgerock.org/confluence/display/openam/OpenAM+Roadmap
Yes, no question. No one wants to use a SOAP/XML standard from 2005 (pre-mobile) when they can use a JSON/REST API from 2014. See Gluu's protocol predictions: http://www.gluu.co/sso-protocol-predictions
If you doubt it, see Forrester's predictions...
http://www.gluu.org/blog/wp-content/uploads/2014/06/eve_uma_irmsummit_2014-300x225.jpg
Notice SAML on the "moderate success" curve, and OpenID Connect on the "significant success" curve.
The problem is that SAML vendors would not agree to breaking changes, and mobile/headless API's broke some of the assumptions made in the design of SAML.
Mike Schwartz
Founder / CEO Gluu
http://gluu.org
I would expect that OIDC will replace SAML based authentication over time.
Apache Fediz (since version 1.3.0) provides support for
* SAML Web SSO
* WS-Federation
* OIDC
The great think about Fediz is, that is also supports a protocol bridge.
So you can login with an IDP using SAML Web SSO and finally login to an OIDC Web Portal.
https://cxf.apache.org/fediz.html
http://janbernhardt.blogspot.de/2015/12/fediz-with-openid-connect-support-and.html
However SLO is currently not supported for OIDC. But since it is an open source project it should be simple to add this, as contributions are always welcome.