ffmpeg.wasmをGitHub Pagesで動かすよ

こんにちは。研究開発室の岡田です。

Heroku 無料枠終了のお知らせの衝撃からだいぶ月日がたち、終了まで残り1か月強となりました。皆様におかれましては、有料プランへの移行準備あるいは、別サービスへの移行作業は進められておられますでしょうか。どうすべきか迷っておられる方は、識者の方々がいろいろと比較検討してくださっていますので、ご参考にされるといいと思います。(参考, 参考, 参考, 参考)

私も例にもれず、実験的なアプリはHerokuにデプロイするのが常であり、いろいろとお世話になっていました。慣れもあるかもしれませんが、Herokuの開発UXは非常に優れていると感じており、サーバ側で処理が必要となるようなアプリについては、引き続きHerokuを使ってもいいかなと考えています。一方で、サーバ側の処理がない、いわゆる静的なアプリについては、ソースコードと一緒にリポジトリで管理できるので、GitHub Pagesがお手軽でよさそうだなと考えています¹。

さて、私がHerokuにデプロイしていたアプリにはffmpeg.wasmを利用したものが幾つかあるのですが、実はこれをGitHub Pagesにデプロイする際には問題が発生します。ffmpeg.wasmを使用したことがある方にはおなじみの話だと思いますが、例のCOOP, COEP制限に引っかかってしまいブラウザで処理が行えなくなってしまうのです。今回は、これについて、簡単な説明と回避方法についてご紹介したいと思います。

---

1. 最初からHerokuではなく、GitHub Pagesで動かしておけよ、という突込みはごもっともですが、開発環境を流用していた関係で、「まぁHerokuでいいか」ということになってました。そういう方、結構おられますよね？↩

Amazon Chime SDKでセンターフレームを作る

こんにちは。研究開発室の岡田です。

Amazon Chime SDK for Javascriptのバージョンが3.x系になって久しいですが、私がOSSで公開しているデモも漸くv3.xに対応させることができました。v2.x系からv3.x系への移行の手順は公式のドキュメントに記載されていますので、これから移行を考えておられる方はそちらを参考にされるとよいと思います。

今回はSDKの移行に伴い、デモに簡易版センターフレーム(Center Stage)を追加したので、その実装方法についてご紹介したいと思います。

つくったものはこんな感じのものです。

Vue.jsなどSPA実装されたエラーページをSpring Webの「404 Not Found」エラーページとして表示するには

みなさんこんにちは。エンジニアの佐藤です。今回はSpring MVC(Webサーバー機能)のエラー処理に関するお話です。

先日筆者は「Spring Framworkの『404 Not Found』エラーページをVue.JSで表示したい」という相談を受けました。

Vue.JSは主にSPA(Single Page Application)を実現するためのフレームワークであり、今回のプロジェクトでもその目的で使われていました。SPAでは、WebページのユーザーインターフェイスはすべてJavascriptアーカイブで実装され、WebサーバーはSPAモジュールから発信されるAPIリクエストを処理する実装になります。今回もそのように実装されており、APIサーバーはSpring MVCで開発されており、SPAのJavascriptアーカイブもここに静的リソースとして配置されていました。

SPA実装では通常、HTMLページのリクエストは最初のJavascriptアーカイブを配置する目的でしか使われません。しかし例外があり、それはディープリンクです。

このプロジェクトの場合、メールに記されたリンクを利用者が踏むというシナリオがあり、その場合はWebサーバーがそのHTTPリクエストを受けます。APIしか実装せず、初回リクエストしか準備のないWebサーバーに、このディープリンクを処理させることができるのでしょうか？それは可能で、以下のような実装になります。

1. ディープリンクに対応するハンドラを記述し、Javascriptアーカイブ配置ページ(/index.htmlなど)の中身を返す。
2. ブラウザはJavascriptアーカイブ配置ページを読み取り、SPAを開始する。
3. 開始したSPAは、ロケーション(アドレスバー文字列に対応)から自分がディープリンクを開いていることを認識し、対応するルーティング・表示処理を行う。

1の部分の実装例は、例えば以下のようなものです。

@Controller
@RequestMapping("/")
public class DeepLinkController {

    @GetMapping("a_deep_link")
    public ResponseEntity<InputStreamResource> a_deep_link() {
        return returnResource("static/index.html", "text/html");
    } // end of verification

    private ResponseEntity<InputStreamResource> returnResource(String resourcePath, String contentType) {
        InputStreamResource isr = new InputStreamResource(getClass().getClassLoader().getResourceAsStream(resourcePath));
        HttpHeaders headers = new HttpHeaders();
        headers.add("Content-Type", contentType);
        return new ResponseEntity<>(isr, headers, HttpStatus.OK);
    } // end of returnIndex
}

しかし、今回相談されたのは、こういうディープリンクが、「サポート外」のパスだった場合です。否定、invertなのです。バリエーションは無限です。一体どうやれば実装できるのでしょうか？

結論を先に

筆者が試行錯誤の末にたどり着いた実装方法は、以下のようなものです。

• server.error.whitelabel.enabled=false
• server.error.path=/error2
• /error2のリクエストハンドラを作成し、/errorへのリダイレクトを返す処理を書く。
• /errorのリクエストハンドラで、Javascriptアーカイブ配置ページ(/index.htmlなど)の中身を返す。
• Vue.JSのルーター(ブラウザのロケーション文字列に応じて異なるページ描画を設定する機能)で、/errorを設定する。

実装方法の解説

• server.error.whitelabel.enabled=false

Spring MVCには「ホワイトラベルエラーページ」というものが用意されており、既定では、HTTPリクエスト処理で例外が発生した場合は、その例外の内容を表示する開発時用のページが表示されます。今回はエラーページはSPAを実装するVue.JSで作ることになっているので、この機能は無効にします。

• server.error.path=/error2

ここが、今回の実装の核心部分です。Spring MVCでは、HTTPリクエストハンドルの過程で発生したエラーを、このリクエストパスに対応するコントローラに通知する仕様になっているようです。ようなのです、と書いたのは、筆者は結局Spring MVCのどこでこの処理が書かれているのか、見つけることができなかったからです。ここではそういうものと考えたいと思います。

• /error2のリクエストハンドラを作成し、/errorへのリダイレクトを返す処理を書く。

/error2のコントローラには、/errorへのリダイレクト処理を書きます。以下のような感じです。

@RequestMapping("error2")
public ResponseEntity<String> error(HttpServletRequest req, HttpServletResponse res) {
    final int status = res.getStatus();
    final String contextPath = req.getContextPath();
    headers.add("Location", StringUtils.join("/error?code=", status));
    return new ResponseEntity<>(headers, HttpStatus.FOUND);
}

/error2というのはもちろん、例えばの話で、その後のリダイレクト処理で利用する/errorと重ならなければ何でも構いません。Spring MVCのエラー処理の仕掛けを利用しつつ、リダイレクトによりディープリンク処理に持ち込むところがポイントです。

ここまで来たら、あとは冒頭に紹介したディープリンクと同じです。

• /errorのリクエストハンドラで、Javascriptアーカイブ配置ページ(/index.htmlなど)の中身を返す。
• Vue.JSのルーター(ブラウザのロケーション文字列に応じて異なるページ描画を設定する機能)で、/errorを設定する。

失敗した作戦と理由

(以下は失敗談や筆者の所感なので、読み飛ばしていただいても構いません。)

このブログを書こうと思ったのは、表題のような実装について解説したブログを、どこにも発見できなかったからです。この実装にたどり着くまでには様々な試行錯誤がありました。以下は失敗談ですが、何かの参考になるかもしれないと思い、共有させていただきます。

フィルタ

Spring Securityでは、ログイン処理にフィルタを設定することができます。

Spring Security Architecture https://spring.io/guides/topicals/spring-security-architecture/#web-security

最初はこの機能を使い、ワイルドカード指定したURLでリダイレクトを設定すればいいだろうと思っていたのですが、挫折しました。

ワイルドカードだけでは、サポートするURI以外を全部という指定はできないことに気がついたからです。。

コントロールアドバイス(例外ハンドラ)

Spring MVCコントローラの種類によらず、リクエストハンドル処理で起こった特定の例外を集中的にハンドルする仕掛けがあります。この仕掛けでは@ControllerAdviceと@ExceptionHandlerアノテーションを設定し、例外ハンドラを設定します。

Global Exception Handling https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc#global-exception-handling

「該当URLが無かったときも、これで集中的に拾えるのでは？」と思いましたが、そうは行きませんでした。

まず、spring.mvc.throw-exception-if-no-handler-foundをtrueに変更しなければなりません。

https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.web.spring.mvc.throw-exception-if-no-handler-found

それはかまわないのですが、このフラグをtrueに設定すると、NoHandlerFoundExceptionに様々な例外が通知され、「サポートサれていないURIのすべて」とは異なることがわかりました。

また、静的リソースハンドラのソースコードを見てみると、例外を投げずに直接 404 NotFoundをHttpServletResponseに書き込んでいる実装もあり、サポートサれていないURIの中には例外スローを経由しない場合もあることに気付かされました。

インターセプタ

Spring MVCにはインターセプタと呼ばれる、フィルタと似た仕掛けがあります。

1.11.5. Interceptors https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-config-interceptors

様々なリクエストハンドルステージで仕掛けられ、postHandleやafterCompletionなどもありますので、いろいろ処理して最終的に404 NotFoundとなった処理結果について、リダイレクトに変更すればよいのではないか？というアイディアもありました。

しかし、postHandleやafterCompletionでは、リクエスト処理をここで完結させるという機能がありません。ハンドルするのは良いのですが、既に処理フローの決まっているレスポンスを変更して、その後の処理がおかしくなるのは困ると思いました。

多機能だが難解なSpring Framework

Spring Frameworkを使ったWebサーバーの実装は、定番の一つとして普及しているように思えます。アノテーションを付けたクラスを配置してSpringApplicationを開始すると、驚くほど高機能なアプリケーションを少ない記述量で実現できます。6年前に初めて手がけてから今回まで何度か使っていますが、うまい仕掛けだと思います。

しかし一方で数年来改善されていない問題もあると思います。文献の不足です。

不正確かもしれませんが、ReactやFlaskは、結構Google検索だけで何とかなってしまうことが多いのですが、Spring Frameworkはそうは行きません。今回もそうでしたが、結局ライブラリの裏側、ソースコードの読解まで踏み込む必要が生じることが多いのです。Spring Framworkには長い歴史があり、過去何度か大幅な改定をしているため、古い時代の巷情報が検索されてくると紛らわしいという問題もあります。

ソースコードを含めたドキュメントの探し方をノウハウとして持っていないとなかなか使いこなせないフレームワークだと思います。

最後までお読みいただきありがとうございました。

Remote Audio forwarding with PulseAudio with complete setup

This is Shuochen from R&D research division from Flect. In this blog I would like to demonstrate how to setup PulseAudio so you can forward audio from local PC to the remote instance.

Introduction

What is audio forwarding? Why do we need it?

First of all, I would like to explain what is audio forwarding. Audio forwarding is the act of redirecting the sound stream from one device to another device​. The way to achieve audio forwarding depends on the Operation System (OS), in this blog we focus on Linux based systems and Mac OS because PulseAudio is designed for the Linux system.

Now to answer the question on why do we need audio forwarding. Imagine you live in a two floor house and you have two laptops. One laptop is upstairs and one laptop is downstairs. Suppose you want both laptops to play the same music. How would you achieve that? This is done by audio forwarding, we are redirecting the audio output from one laptop to another laptop so both laptop can play the same music. The same idea can be extended to a remote device anywhere in the world that is connected to the internet.

Now suppose we have a remote cloud instance. The remote instance could be a Google instance, an AWS instance or an Oracle instance. However, they share the common characteristics of not having a sound card or microphone. Even if they do have a sound card, you cannot hear them due to physical distance is too far away! If you are developing an audio application, how can you hear what is playing on the remote instance? Again we can achieve this with audio forwarding. We stream the audio output from the remote instance to the local computer so we can hear it. It is also possible to do the reverse: we can stream our microphone input from the local computer to the remote instance.

There are multiple softwares which allow audio forwarding, with PulseAudio being one of the possible choice. The reason that I chose PulseAudio is that it is installed by default on Linux computers.

Types of audio forwarding

Before moving to explain on how to achieve audio forwarding, it is necessary to understand that there are 2 types of audio forwarding. Audio forwarding within the same network and audio forwarding for different networks.

Audio forwarding within the same network is the first example which we share the audio between laptops in the same house. The devices could be further away (for example same building), but the idea is the same. They are connected to the same network. When in the same network, the device can access to each other directly using the private IP address. Therefore, audio forwarding within the same network is easy. There are multiple ways to achieve audio forwarding: direction connection, tunneling, mDNS services and RTP protocol. In this blog I will focus on setting up audio forwarding in different networks.

Usually, it is common for devices to be in different networks. It is common for our devices at home to join a router and then connect to the internet. This means the devices are typically behind NAT (Network address translation)​. In other words, it is not directly accessible from the internet. This is desired for security reasons but it creates a problem for audio forwarding. If it is not directly accessible then we cannot forward any sound stream.

Therefore the first step for audio forwarding is to establish a connection between the remote instance and the local PC. There are 2 ways this can be achieved and I will explain each of the method in the next section.

Setting up connection

Port forwarding

The first method, which is straightforward in the concept but more complicated in the setup is to use port forwarding. You may already have done port forwarding before for certain games (for example Minecraft).

It is not a good idea to allow any traffic to access your local computer without any restrictions. What we will do instead, is to allow the internet to access the local computer only on one port. Because PulseAudio uses the port 4713 by default, this will be the port that will be port forwarded. Basically this means, any request for the port 4713 to your public ip address will be forwarded to your local computer.

Unfortunately, the steps of port forwarding depends on the router so there is no universal guide. The website https://portforward.com/, has a good comprehensive summary for how to do port forwarding.

After you have completed the port forwarding, please do check for the firewall and allow for access to the port 4713. The firewall setting includes both the firewall list of the router and the firewall options of the OS.

To test for connection, type telnet ip_address 4713 in the remote cloud instance.

SSH

SSH is the secure alternative for establish connection between the remote server and the client. In particular we will use SSH -R option to establish a reverse tunnel from the remote server back to the client. Normal SSH establishes the connection from the client to the server. However, we also require the reverse process for PulseAudio to work. That is, establish the connection from the server to the client. This is not difficult because usually remote instance requires SSH to connect to it anyway. We are just including additional parameters to also create a reverse tunnel.

In order to set up a reverse tunnel, run the command ssh –R port1:127.0.0.1:4713 username@ip_address when connecting from the client to the server. Port1 can be any port number of your choice, as long it is not used. 127.0.0.1 means local host, because we are forwarding the request from the localhost of the server back to the client. Finally, 4713 is the default port number used by PulseAudio. Unless you have a good reason to change it, use this port number.

Again to test the connection, type telnet ip_address 4713 in the remote cloud instance.

Installing required modules​

Installing required modules should be rather simple. The required modules are SSH and PulseAudio itself. Both SSH and PulseAudio should be installed by default. If for some reason PulseAudio is not installed on the distribution, install it with sudo apt install pulseaudio

For Mac OS, install it with brew install pulseaudio

Setting up the server

Just to be clear, when I use the term server here it means the PulseAudio server, not the SSH server which you connect to. PulseAudio server needs to be the device with the actual sound device on it, otherwise we will not hear any sound output.

Edit the configuration file

After installing PulseAudio, we need to edit the configuration file. We edit the configuration file with sudo nano ~/.config/pulse/default.pa. In this file (default.pa), enable the line load-module module-native-protocol-tcp auth-anonymous=1​. In other words, delete the * sign in front for the line to take effect. auth-anonymous=1​ means we do not restrict on who can connect to the server. You can set the IP of the client to only allow the remote instance to connect it.

Restart the service

After changing the configuration, it is necessary to restart the PulseAudio service. For Mac OS, type brew services restart pulseaudio in the terminal.

For Linux distrubutions, first type pulseaudio -k, then type pulseauido --start

Setting up the client

Now we need to repeat the same steps to set up the PulseAudio client. In this case, PulseAudio client is the the device on the remote client, which will connect to the PulseAudio server. It is possible for multiple clients to connect to the same server, should it be required.

Edit the configuration file

Again, we need to edit the configuration file with sudo nano ~/.config/pulse/default.pa. In this file (default.pa), enable the line load-module module-native-protocol-tcp​. In other words, delete the * sign in front for the line to take effect. auth-anonymous=1​ is no longer required because the client side does not perform authentication.

In addition, 2 additional modules should be enabled. Module-tunnel-source and module-tunnel-sink. Module-tunnel-sink-new provides audio forwarding for the sink, which is the speaker output from the remote cloud instance (client), back to the server (local computer). Module-tunnel-source-new provides the audio forwarding of the microphone input from the server to the client.

To enable module-tunnel-sink-new module, enable the line load-module module-tunnel-sink-new server=127.0.0.1:6666 sink_name=Sound​. This is assuming you have provided a reverse tunnel in SSH with the port number 6666. In the case of port forwarding, the server argument would your global IP of your local computer and the port number should be 4713.

For the load-module module-tunnel-source-new module, enable load-module module-tunnel-source-new server=127.0.0.1:6666 source_name=Mic.

Both the argument sink_name and source_name are optional. Restart the service as before.

Test the connection

That is all the steps required to set up the PulseAudio. Now any audio you play on the remote client will be forwarded back to the local computer and the any microphone input from the local computer will be forwarded to the remote client. This is very convenient for developing audio applications on the remote client.

Optional adjustment

If the PulseAudio server has multiple devices. It is possible to specify which device to use for audio forwarding. We can select the device by its index (the information is shown by pacmd list-sources or pacmd list-sinks) in this way:​

pacmd set-default-sink 1, pacmd set-default-source 1

Restart the PulseAudio on both the server and client to take effect​.

Reference links

Complete guide on port forwarding
https://portforward.com/
PulseAudio wiki
https://wiki.archlinux.org/title/PulseAudio#Networked_audio
PulseAudio official page
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-cli-protocol-unixtcp

Amazon Chime SDKの新機能 背景置き換え機能(≒仮想背景機能)を使ってみた

こんにちは。研究開発室の岡田です。

先日(2022/1/25)、Amazon Chime SDK for Javascript に待望の背景置き換え機能が追加されましたね。

aws.amazon.com

これまで、Amazon Chime SDK のアプリ開発者は独自の方法で仮想背景機能を作成する必要がありましたが(例)、AWS 公式での今回の機能追加によって、よりシンプルに仮想背景機能を作成することができるようになりました。

また、この機能は以前より提供されていた Amazon Chime SDK for Javascript の Video Processing API を使用して実現されているので、この機能を使用していた開発者(例えばBackground Blur)にとっては、ほとんど追加の学習なく使用できるようになっています。

それでは、どのような感じで動くのか、仮想背景機能を作成して試してみましょう。作成した仮想背景機能の動作は次のような感じになります。

MuleSoft開発 Salesforceを使用してSSOを実現する - OpenID Connect編

こんにちはCI事業部の川瀬です。

前回に引き続きSalesforceを使用してSSOを実現したいと思います。今度はOpenID Connectを使用します。前置きは省略し実際にやっていきましょう！

では、Salesforceの設定から実施していきましょう。途中までは、前回のSAML編と同じです。

1. Salesforceで「私のドメイン」を設定する。

2. Salesforceで「IDプロバイダの有効化」を有効化する。

3. Salesforceで「接続アプリケーション」を作成する。

下記の画面で、「接続アプリケーション名」、「API 参照名」、「取引先責任者 メール」に対し、任意の値を設定してください。

下記の画面で、「OAuth 設定の有効化」をチェックしてください。

3.1 「コールバック URL」の設定

コールバック URLには何を設定するのでしょうか？どこを探してもそのような記事はないです。そうなんです、この時点では設定すべき値はどこにも存在しないので、「https://hoge.hoge.com」で大丈夫です。

3.2 「選択した OAuth 範囲」の設定

選択した OAuth 範囲には何を設定するのでしょうか？全部設定してしまうことが簡単ですが、気になりますよね。これもどこを探しても、何を設定すべきかを記載している記事はないです。
ここでは次の2つを設定すれば大丈夫です。
・ID URL サービスにアクセス
・一意のユーザー識別子にアクセス
設定したら、「保存」ボタンを押します。

3.3 「コンシューマ鍵」と「コンシューマの秘密」

保存ボタンを押すと以下の画面に遷移します。そうしたら、「コンシューマ鍵」と「コンシューマの秘密」を保存しておいてください。後で使います。

4. 「Identity Provider」の設定

ここからは、Anypoint Platformの作業になります。 Access Managementの「Add Identity Provider」→「OpenID Connect」を選択します。

4.1 「Use manual registration」の設定

以下の図で「Use manual registration」をクリックします。

そうすると、次の図のようになります。

4.2 「Name」の設定

はい、適当に任意の値を設定してください。

4.3 「Client ID」の設定

手順3.3で取得した「コンシューマ鍵」を設定してください。

4.4 「Client ID」の設定

手順3.4で取得した「コンシューマの秘密」を設定してください。

4.5 「OpenID Connect Issuer」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2​/clients
≪MYDOMAIN≫は手順1で取得した値です。

4.6 「Authorize URL」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2/authorize

4.7 「Token URL」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2/token

4.8 「User Info URL」の設定

https://≪MYDOMAIN≫.my.salesforce.com/services/oauth2/token
はい、ここまできたら「Save Changes」を押してください。

4.9 「redirect URI」の取得

保存したら、再度、開いてください。図のようにredirect URIが設定されています。

5. Salesforceに「コールバック URL」を設定する

手順3.3で「https://hoge.hoge.com」を設定しましたよね。これを手順4.9で取得した値に置き換えます。

6. SSOの確認

Anypoint Platformにログインしている場合は、一旦、ログアウトし、下記のURLブラウザに入力してください。 https:/anypoint.mulesoft.com/accounts/login/DOMAIN-NAME
DOMAIN-NAMEはAnypoint Platformaのドメインです。組織ドメインは以下の図の箇所で確認できます。

Salesforceのログイン画面がでてきてログインできましたか？成功するとAnypoint Platformのユーザーに以下のようなユーザーが登録されています。

前回に引き続き、「OpenID Connect」を使用したSSOの設定方法を紹介しました。分かると簡単なのですが、「コールバック URL」など肝心なところの説明、設定方法が欠落しておりイライラしてしまいます。

なんでこんなことを紹介したかというと、勿論Salesforceを導入しているならそちらでアカウント管理したほうが便利ですよね。更に、API Community Managerなるものがあり、こちらの事前設定で必要になるのです。

docs.mulesoft.com

次回は、「クライアント認証」か「Standalone」について説明するつもりです。

MuleSoft開発 Salesforceを使用してSSOを実現する - SAML編

こんにちはCI事業部の川瀬です。

今回はSalesforceを使用してSSOを実現したいと思います。具体的はAnypoint Platformにログインするときに「Salesforceアカウントを使用」しますということになります。

具体的には以下のサイトを手掛かりに設定を行うのですが、よく分からないので、図で示しながら、簡潔に説明していきます。 docs.mulesoft.com

では、Salesforceの設定から実施していきましょう。

1. Salesforceで「私のドメイン」を設定する。

2. Salesforceで「IDプロバイダの有効化」を有効化する。

3. Salesforceで「接続アプリケーション」を作成する。

下記の画面で、「接続アプリケーション名」、「API 参照名」、「取引先責任者 メール」に対し、任意の値を設定してください。

下記の画面で、「SAML の有効化」をチェックしてください。そうすると、いくつかの項目は自動で生成されるのでそのままで大丈夫です。 次に、「開始 URL」、「エンティティ ID」、「ACS URL」に対し値を設定していきます。

3.1 「開始 URL」の設定

「https://anypoint.mulesoft.com」を設定してください。

3.2 「エンティティ ID」の設定

Anypoint Platformの組織ドメインをDOMAIN-NAMEとすると、「DOMAIN-NAME.anypoint.mulesoft.com」を設定してください。 組織ドメインは以下の図の箇所で確認できます。

3.3 「ACS URL」の設定

私がいろいろ調べたのですが、よく他の記事では「ACS URLはサービスプロバイダで取得した値を設定してください。」と記載されています。じゃ、MuleSoftの場合は何ですか？となります。 どこかに記載してあるのかもしれませんが、この段階では実は存在しないのです！ここがポイントです。 なので、適当に「http://hoge.hoge.com」で最初は大丈夫です。この状態で「保存」ボタンを押します。

3.4 「メタデータ」のダウンロード

下記の画面(アプリケーションマネージャで作成した接続アプリケーションのManageを選択)で「メタデータのダウンロード」を選択し、Salesforceの設定情報をダウンロードし保存します。

4. 「Identity Provider」の設定

ここからは、Anypoint Platformの作業になります。 Access Managementの「Add Identity Provider」→「SAML 2.0」を選択します。

4.1 「メタデータ」のアップロード

手順3.4でダウンロードしたメタデータを「Chose file」を選択しアップロードします。

4.2 「Name」、「Sign Off URL」、「Audience」の設定

アップロードとすると、以下の図のようになります。アップロードしたほうが遥かに簡単です。

「Name」は適当に設定してください。
「Sign Off URL」は「≪Issure≫/services/auth/idp/saml2/logout 」と設定してください。
≪Issure≫はメタデータをアップロードした時に設定されています。4.1の図を見てください。

「Audience」は手順3.2と同じで「DOMAIN-NAME.anypoint.mulesoft.com」となります。 設定したら、「Save Changes」を押します。

4.3 「ACS URL」の取得

保存したら、再度、開いてください。図のようにACSが設定されています。

5. Salesforceに「ACS URL」を設定する

手順3.3で「http://hoge.hoge.com」を設定しましたよね。これを手順4.3で取得した値に置き換えます。

6. SSOの確認

Anypoint Platformにログインしている場合は、一旦、ログアウトし、下記のURLブラウザに入力してください。 https:/anypoint.mulesoft.com/accounts/login/DOMAIN-NAME
DOMAIN-NAMEは手順3.2で確認したもの

Salesforceのログイン画面がでてきてログインできましたか？成功するとAnypoint Platformのユーザーに以下のようなユーザーが登録されています。

今回は、SAMLを使用しましたが、次回はOpenID Connectで設定する方法を紹介します。こちらも、少しクセがあります。