just create some small outlook addin for office365 and tried to enable single sign on via MS account. Deployed it to some simple 3rd party server with manifest by path: https://domain1.domain2.com/subfolder. In manifest defined WebApplicationInfo there put info for SSO as described in docs:
<Id>AppId</Id>
<Resource>api://domain1.domain2.com/appId</Resource>
but everytime I got OfficeRuntime.auth.getAccessToken: {"name":"Invalid application resource Url provided.","message":"Invalid resource Url specified in the manifest.","code":13004}
Looks like something is wrong with Resource but I have no idea that exactly is wrong there.
Thanks.
Make sure the URI corresponds to the Resources section of your add-in's manifest file. The subfolder can be missed in the path.
The Resource element contains the same URI (including the api: protocol) that you used when registering the add-in with the Microsoft identity platform. The domain part of this URI must match the domain, including any subdomains, used in the URLs in the <Resources> section of the add-in's manifest and the URI must end with the client ID specified in the <Id> element.
See Enable single sign-on (SSO) in an Office Add-in for more information.
Related
I want to do OpenID Connect 1.0 authentication for frontend users on my site.
In order to do so, I've developed an authentication service (as described in the docs). Within this service I'd like to access TypoScript configuration values to fetch the OpenID configuration (.well-known-URL, client ID and secret).
To do so, I simply inject TYPO3\CMS\Extbase\Configuration\ConfigurationManagerInterface into the authentication service - but this class only wraps the real configuration manager, which in this case is an instance of TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager - although I am in frontend context. This also affects other places, for example is TYPO3 not able to get the correct plugin configuration (because it is not present in the backend).
I've tracked this down to TYPO3\CMS\Extbase\Configuration\ConfigurationManager::initializeConcreteConfigurationManager, where the existence of $GLOBALS['TYPO3_REQUEST'] is checked - if it does not exist, the BackendConfigurationManager is used as fallback.
So my question: How do I correctly fetch TypoScript configuration within a TYPO3 authentication service?
As already written by Chris. TypoScript is not initialized at this time and I also don't suggest to do so by yourself.
Your options are:
Use the extension configuration which is described here
Use the site settings which are described here
Which one you want to use depends on the usecase. The extension configuration is global and even more lowlevel as now site is used. If you need different setttings for a multi-site installation, the site settings are the prefered choice
We have recently migrated to a new hosting environment so have installed a fresh instance of Shibboleth. When we generate sp metadata files, the urls are non-secure (ie http) even though the url used to generate the metadata uses https.
When using the test connection from our own Azure AD system, we see the obvious error: "The reply URL specified in the request does not match the reply URLs configured for the application:"
I have limited knowledge of configuring the system beyond working on shibboleth2.xml and attribute-map.xml so would be very grateful if anyone can point me in the right direction to fix this.
I'm not sure if you managed to configure it but i'm currently working on this as well, and i think i can help.
So the ReplyURL you need to provide in the Azure Portal, is the reply URL that accepts the authentiaction reply message from the identity provider.
In the case of Shibboleth it is:
http[s]://yoursitename/Shibboleth.SSO/Auth/Saml
So if your webpage is for instance:
https://localhost/Foo
The replyURL should be:
https://localhost/Shibboleth.SSO/Auth/Saml
Notice that the page "Foo" is not in the replyURL.
After the authentication the browser should send the IDP reply to https://localhost/Shibboleth.SSO/Auth/Saml, after which Shibboleth should redirect you back to https://localhost/Foo
At least that's the default behaviour.
I'm getting the this error when I try to use an ASP.NET WebService through an MSSOAP Client:
"WSDL Reader: Loading of the WSDL file failed HRESULT=0X80040154 Class not registered - Client: An
unanticipated error occured during the processing of this request.HRESULT=0x1812040:Class not registered."
At first I thought the SOAP library was not properly registered. But when I debugged the code I realized the error was being raised at the time of reading the web service definition (The Soap client does get created).
SOAPClient.mssoapinit "wsdl_URL"
Now, the issue only occurs when I execute the code as certain account (as for the rest of the accounts the code works pretty well). The original client is a Classic ASP page but I've reproduced the problem using a vbs script.
I run the script under several accounts, but just one presents the wsdl-reading failure.
I've granted reading permissions to the directory that contains the
asmx file to the failing account.
I've changed the physical path of the virtual directory where the
webservice is hosted to a general non-particular-profile location
like C:.
Ironically the application pool identity of the web application is
the account that presents the failure.
All the accounts can read the wsdl file through a browser just typing
the url (but still one of them can't from client code)
Do I need to grant additional permissions for the account in order to read the web service definition and initialize the soap client?
I have a REST api in my web application where I get cas ticket generated by another webapp.
That webapp intern use cas20proxyticketvalidator to validate the ticket. Therefore, I also use Cas20ProxyTicketValidator in my custom filter to validate the ticket.
But it always give me following error:
ticket = ST-148008-jWXKeEdHkxmuktvYqXF6-cas
org.jasig.cas.client.validation.TicketValidationException:
ticket 'ST-148008-jWXKeEdHkxmuktvYqXF6-cas' not recognized
at org.jasig.cas.client.validation.Cas20ServiceTicketValidator.parseResponseFromServer(Cas20ServiceTicketValidat
or.java:86)
at org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java
:217)
Why my ticket is not recognized?
The way that cas validates tickets is:
Your client (or the other web app) requests a ticket from the relay
server for a particular service, for example case
http%3A%2F%2Fwww.mywebapp.com
The cas server generates a row that stores the user's ssoguid, the service and the ticket. It returns the ticket to the client (or
other web app)
The client (or other webapp) sends the ticket to your server
Your server then sends a request to the serviceValidate endpoint of the cas server with the ticket and the service,
http%3A%2F%2Fmywebapp.com
The cas server uses the ticket and service pair to find the row it generated. If it finds the row it: a) checks to see if the
service is real by sending a request to that url b) deletes the row
to invalidate the ticket after this validation check c) it returns
the user attached to the ticket to your server. Now the ticket can
not be validated again.
The problem you are experiencing could arise for several reasons:
The ticket has already been validated (I don't think that is the
case for you)
The service you send when generating the ticket is different to the service you send to the serviceValidate endpoint (they have to
be identical). (I would guess that this is the problem you are
experiencing, especially if another webapp generated the ticket. The
cas server would have http%3A%2F%2Fotherwebapp.com on file but would
be trying to find a row with http%3A%2F%2Fmywebapp.com, which
doesn't exist because you didn't create it)
The service sent can
not be contacted by the relay server (I'm not exactly sure of the
details about how this works or exactly when the check it done but
it is recommended that you use a service that can be contacted)
Check the serviceUrl generated, so change the log level for package org.jasig.
With SpringBoot, in the application.properties add
logging.level.org.jasig=DEBUG
In the console
org.jasig.cas.client.util.CommonUtils : serviceUrl generated: https://xxx
Verify and adapt your cas.client-host-url in the application.properties
## CAS[2.0]
cas.server-url-prefix=https://cashost.com/cas
cas.server-login-url=https://cashost.com/cas/login
cas.client-host-url=xxx
cas.validation-type=CAS
Be careful with cas.client-host-url, no slash at the end of url.
Don't forget mvn clean package after modifying .properties
Trying to understand options for attatching input files can to a quote/project when using the Web Service API for Partners 1.0.
We have figured out how to use the login and the createSimpleQuote SOAP methods to create a Quote as a customer.
The thing step that we are struggling with now is how to upload the input files that are to be referenced in the files section of the payload to createSimpleQuote.
<par:files>
<par:name>?</par:name>
<par:category>?</par:category>
<par:url>?</par:url>
</par:files>
Ideally we like the url element to reference local files (using file:///tmp/sample.pdf) as it is done in the java usage example).
What options do we have for uploading files?
How do we get the local path value of an uploaded file that can be used in the createSimpleQuote SOAP call?
Please advice?
It is not possible to upload files from your local disk to XTRF via Web Service API.
In order to reference a file using file:// protocol, the file must be visible to XTRF. There are several options to do this:
the file should be uploaded before sending request to the XTRF Web Service API
request to the XTRF Web Service API should be sent from the same machine where XTRF is running
remote disk where the file is stored should be mounted (e.g. using CIFS, NFS or another network filesystem protocol) on the machine where XTRF is running
Note that it is also possible to refer to a file using other protocols, e.g. http:// or ftp://.