Unicorn Cloud ID Manager (以下UCIDM) の開発チームのふりかえりについて紹介します。UCIDM チームのふりかえり UCIDM の開発は2022年11月から始まり、本稿執筆時点で1年半の間、課題管理を土台にした イテレーション開発 を採用して取り組んでいます。アジャイル開発という用語が生まれる以前からあった手法ですが、昨今の雰囲気ではアジャイル開発の一種とみなしてよいでしょう。イテレーションという2-4週間程度の期間を区切って開発を繰り返す、タイムボックス方式で開発します。スクラム開発に慣れている方向けに言えばスプリントとほぼ同じものと捉えてもらっても構いません。UCIDM 開発では2週間のイテレーション6つ (3ヶ月) を機能開発に、2つ (1ヶ月) を QA テスト期間として合計8イテレーション (4ヶ月) を1回の開発期間としています。補足として、UCIDM の開発チームはほぼフルリモートワークで開発しています。メンバー全員が顔をあわせるのは月に2日あるかないかです。本稿ではイテレーション開発の詳細については踏み込まず、それはまた別の記事で書きます。ふりかえりなくして成長 (改善)なし私は何度も機会がある度にチームにこの言葉を啓蒙しています。昨今さまざまな開発をうまくまわすためのプラクティスが共有されるようになりました。うまく機能している開発チームはふりかえりを当たり前にしていると思います。しかし、私が過去に働いてきた、いくつかの会社／チームの経験則で言えば、日本の会社ではふりかえりをやらない、もしくはやっても形骸化しているところが多かったです。ふりかえりが形骸化している組織でよく起きるのは「みんながんばった」で済ませることです。実際はそんなことはなくて、一部の開発者に大きな負担を強いていたり、組織としての意思決定やプロセスに課題があったとしても、ふりかえりで議論したりはせず、なかったことにするケースがあります。とくに課題の規模が大きかったり煩雑度が高いほど思考停止してスルーされがちです。先送りとも呼びます。これは責任を取りたくないという日本人のメンタリティと相性がよいからではないかと私は考えています。マネージャーとしてチームビルディングでやることの1つに、このチームの開発プロジェクトで起きるすべての事象に対する責任はマネージャー

Unicorn Cloud ID Manager (以下UCIDM) の開発チームで新たに始めた取り組みがあります。2023年末、とあるイベントに私が参加したときにそういった読書会？勉強会？があることを知って、1ヶ月ほど外部イベントに参加して実地でイベント運営を学び、1月後半から社内版イベントを企画してチームメンバーとやり始めました。これはとてもよいイベントだと私は考えていて定期開催してチームに根付かせようと考えています。テックブログを読む会のオリジナル サイボウズ社の西原さんが本イベントについて記事を書いています。オリジナルのイベントの主旨や運営は次になります。ブログを見つけて読んで感想書いてそれを肴に交流する会を30分でやりきっています 実際にどんなイベントなのか 本稿を読むよりも、実際にイベントに参加して一緒にやってみる方が手っ取り早いかもしれません。準備なしのたった30分のイベントです。たまにお休みしているときもありますが、ほぼ毎週月曜日の18:30から開催しています。記事を読む時間も含めて30分なのですから、ほとんどの人にとって忙しくて参加できない、時間をとれないといったことはないと思います。いきなりイベントへ行って、訳も分からずやってみて、そこで得た所感がすべてです。テックブログ一気読み選手権 社内版テックブログを読む会のやり方 このイベントの導入は半ば強引に私が進めました。当初メンバーから開発の時間が少なくなることへの懸念の声もありました。私自身、同期的なチームイベント (要は会議) をなるべく減らしたい方です。開発者の懸念もわかります。また別の記事で書きますが、UCIDM チームは開発の定例会議を隔週で1時間しか行っていません。残りの時間をすべて開発に割り当てています。この会議時間の少なさは昨今のアジャイル系の開発方法論においては特殊な方だと思います。そんな私が会議時間を増やそうと提案しているのですから、これはちょっとした事件です。このイベントには価値があるということを、コミュニティイベントや勉強会に15年以上参加してきた私の直感に訴えるものがあります。たった30分のイベントなのに価値がある。価値のあることだけを30分に凝縮している。このイベントを企画するには多くの試行錯誤を経て洗練されていることが伺えます。UCIDM チームでは「テックブログを読む

先日 SvelteKit のコンパイルの仕組み について調査しました。そのときに Vite というビルドツールによって ES モジュールをインポートする形でページが構成されていることもわかりました。Vite の バックエンドとの統合 というドキュメントには従来のバックエンドに Vite アプリケーションを組み込む方法について説明されています。SvelteKit アプリケーションも Vite アプリケーションの1つです。エンドポイントのパスやエントリーポイントを調整することで組み込みできないか？というのが本稿の主題です。マイクロフロントエンドの動機づけ 考察を始める前に マイクロフロントエンド というキーワードもよくみかけるので一緒にみておきましょう。マイクロサービスのフロントエンド版という、大雑把な理解でもそれほど間違っていないと思えますが、メルカリ社の記事がわかりやすかったので紹介します。フロントエンドエンジニアは Micro Frontends の夢を見るか この記事ではマイクロフロントエンドを成立させるために3つの原則があると説明されています。技術: それぞれのチームの技術が他のチームに影響を与えない コードやルール: コードは共有せず、コーディングルールも独立している デプロイ: チームがそれぞれ独立してデプロイできる Microservices と大きく違うのは、Micro Frontends では UI や ビルド、バンドルという概念と、最終的に相当数の Microservices を1つの画面に組み上げる必要があるという点です。そして、マイクロサービスとマイクロフロントエンドの大きな違いの1つとして API を介して協調するマイクロサービスとは異なり、マイクロフロントエンドは1つの画面を組み上げるというところを言及しています。後述しますが、これは本稿でも実際にやってみてかなり難しいというのがわかってきました。もともと私が SvelteKit アプリケーションを組み込みできないかと考えたのは、カスタムテンプレートという要件に対して、機能とデザインという目的の違うアプリケーションを別々に管理できた方が開発にとって都合がよいと考えたからでした。マイクロフロントエンドはまさにそういった概念と相性がよさそうに思います。SvelteKit アプリケーションのレンダ

フロントエンドの技術選定 によって Svelte と SvelteKit を使って管理画面を作ることに決めました。Unicorn Cloud ID Manager (以下UCIDM) の管理画面を SvelteKit を使って開発しています。UCIDM のフロントエンドのアーキテクチャ BFF (Backend For Frontend) サーバーに Node.js を配置し、サーバーサイドレンダリングを採用したフロントエンドを提供しています。マイクロサービスでは一般的なアーキテクチャだと思います。エンドユーザー (ブラウザ) は BFF サーバーに対して認証を行い、BFF サーバーが UCIDM API サーバーと認証します。エンドユーザーは透過的に UCIDM API サーバーが返す情報を参照できますが、直接 UCIDM API とは通信できません。これはセキュリティを担保する上での考慮であったり、将来 UCIDM API 以外にもバックエンドサービスを提供するような場合においても、BFF サーバーがその差異を吸収できるというメリットがあります。そして、この構成をとるためには SvelteKit のサーバーサイドレンダリングの機能が必要となります。カスタムテンプレート エンドユーザーがフロントエンドの画面構成、レイアウト、テーマなどをちょっとカスタマイズしたいという要件があります。SvelteKit アプリケーションのどこにフックすべきかを検討しています。シンプルな実装 もっとも簡単なフックポイントとしては、エンドユーザーが編集した HTML をサーバーサイドから返し、ブラウザ側でそのまま流用してレンダリングする方法です。Svelte では {@html …} というテンプレート構文のタグがあり、このタグを使うと任意の内容を表示できます。<div class="blog-post"> <h1>{post.title}</h1> {@html post.content} </div> 一方でこのタグには注意事項があります。任意の HTML を挿入できるトレードオフとしてセキュリティ上の懸念があります。ドキュメントには次の注記があります。Svelte は HTML を注入する前に式をサニタイズしません。データが信頼できないソースから来る場合、それをサニタイズする必要

これまでもバックエンドに Go 言語を用いて製品開発していることをブログに書いてきました。先日その製品のプレスリリースを行いました。新製品発表、クラウド対応ＩＤ管理製品を新たに提供開始Unicorn Cloud ID Manager (以下UCIDM) という製品名になります。またこの機会に UCIDM タグ も付けました。製品開発の過程で調査した技術情報や開発の話題などをフィルターできます。本稿はその製品開発の裏話の1つとして、github.com/go-ldap/ldap (以下go-ldap) というライブラリへコントリビューションしたことを紹介します。go-ldap は Go で LDAP プロトコルの通信を行うクライアントライブラリです。go-ldap という名前は organization 名でライブラリ名は ldap になります。Awesome Go などをみると、go で実装されたライブラリ名に go- という接頭辞を付けることはよくあります。そのため、ここでは ldap ライブラリのことを go-ldap という organization 名で呼称するようにします。LDAP プロトコルを指しているのか ldap ライブラリを指しているのか、混同しないようにという意図になります。UCIDM のシステム概要 唐突ですが、オンプレミス版の UCIDM システム構成の概要図が次になります。この真ん中の方に Agent と呼ばれるモジュールがあります。Agent は内部向けディレクトリサービスにある OpenLDAP や Active Directory (以下AD) といった LDAP サーバーからエントリーを取得して UCIDM の API サーバーに連携する役割を担っています。大前提として Agent は LDAP プロトコルで OpenLDAP や AD サーバーと通信しなければなりません。LDAP プロトコルの機能を使って変更を検知して ID 連携できる必要があります。

SELinux が有効な環境で OpenAM のログに対してのログのローテートが行われていませんでした。/var/log/messageに以下のエラーが出力されていました。/var/log/message Jun 13 00:00:05 alma9sp2 systemd[1]: Starting Rotate log files... Jun 13 00:00:05 alma9sp2 logrotate[45638]: error: cannot allocate memory [readConfigFile():1806] Jun 13 00:00:05 alma9sp2 logrotate[45638]: error: found error in file openam, skipping cannot allocate memoryはメモリを確保できない旨を示すメッセージです。 しかし、サーバーのメモリは不足しておらず他のログのローテートは成功していました。 (もしメモリ不足であれば、他の処理でも失敗するはずです。)logrotate が失敗したのは SELinux が原因だったのですが、どうしてcannot allocate memoryのメッセージが出力されたのかを調べました。logrotate が失敗した環境 OS は AlmaLinux9 で SELinux が有効な環境です。 logrotateの設定ファイルでログローテートの対象として指定している先はシンボリックリンクです。SELinuxが有効 # getenforce Enforcing logrotateのバージョン # rpm -qa logrotate logrotate-3.18.0-8.el9.x86_64 エラーとなったlogrotateの設定ファイル(openam) /opt/osstech/var/lib/tomcat/data/openam/openam/stats/* /opt/osstech/var/lib/tomcat/data/openam/openam/debug/* { rotate 100 daily su tomcat tomcat notifempty missingok copytruncate olddir old dateext compress nod

バックエンドに Go 言語を用いて製品開発をしています。Go 言語で開発されたアプリケーションはコンテナイメージとしてパッケージングされ、システムは複数のコンテナを組み合わせて稼働します。当初は docker cli を用いたスクリプトで運用していました。製品開発を進めていくうちにコンテナイメージの取得やコンテナの制御に、自分たちの要件にあわせた運用ツールがあるとよいように思えてきました。Docker は Go 言語で開発されていると聞いたことがある人も多いでしょう。github.com/docker にあるリポジトリなどを参照してみるとわかります。私たちは Go 言語でアプリケーションを開発しているので運用ツールも Go 言語で開発することは都合がよいように思いました。実際にそうだと開発してみた後でも思います。しかし、コンテナの運用ツールを開発するにあたり、自分たちが必要とする機能を提供するコンポーネントはどれなのか？何を／どこを調べればよいのか？といった質問に答えるには、いくらか Docker やコンテナ標準化の歴史的経緯や背景を理解しておく必要がありました。本稿では、Docker のコンポーネントを使ってツールを作ろうとしたときに調査した内容を踏まえて、現時点における Docker とは何なのか？を考えてみたいと思います。Docker Engine のリリースノート Docker Engine 23.0 release notes から読んでいきます。2023-02-01 に 23.0.0 というメジャーバージョンがリリースされました。それまでは 20.10.x というバージョン体系だったので大きく変わったことが伺えます。私が関心のある内容を1つ取り上げると Buildx とBuildKit がデフォルトのビルダーになったそうです。RPM で docker-ce をインストールするときに docker-buildx-plugin も要求されるようになりました。Buildx を使うと複数アーキテクチャ向けのビルドができます。バージョン体系の変更について次のように書いてあります。Starting with the 23.0.0 release, Docker Engine moves away from using CalVer versioning, and s

0. はじめに 学認連携の新規接続やシステム更改をされる際、多様な認証方式と認証連携方式を兼ね備えた 「OpenAM」の導入もご検討いただけると、様々な利点を感じていただけると思います。もし本記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。1. 概要 学認を含めた大学様のシングルサインオン系として、これまでもShibbolethとOpenAMとを併用（連携）、 という形で導入いただくことが数多くありました。学認との認証連携接続はShibbolethが担い、 Shibbolethでは実現できないような「レガシーアプリとの認証連携接続」や「複雑な認証フローの実現」を OpenAMが担う、という形です。もちろん今後も併用の形を採ることも可能ですが、OpenAMは直近のエンハンスにて 「学認との接続・運用に必要となる機能」を搭載しましたので、今後はOpenAMのみを導入いただく形も 可能となります。下図のようにOpenAM単独での導入でも、学認・各種クラウドサービス・ レガシーアプリに対し、強力な認証機能によるセキュアなシングルサインオン（SSO）系を実現できます。 2. 学認との接続・運用に必要となる機能の搭載 学認と認証連携するにあたっては、SAMLプロトコルにより認証連携するというだけでなく、学認特有の機能への 対応が必要となります。OpenAMは、この学認との接続・運用に必要となる機能を製品標準機能として搭載しました。具体な機能群は、以下の表の通りです。機能 説明 Shibbolethでの相当機能 送信属性同意機能 SAMLアサーション送信前に、SPに送信する属性についてユーザーに同意してもらう機能 Attribute Release Consent に相当 メタデータ自動更新機能 学認が提供するメタデータから 、SP 証明書などの変更を自動的に読み込んで反映する機能 metadata-providers.xml および reload-metadata.sh に相当 SPへの送信値の生成機能 ユーザーデータに無い値を動的に生成して SP へ送信できる機能 attribute-resolver.xml に相当 SPデフォルト設定定義機能 SP作成時に適用する共通設定を定義できる機能 relying-party.xml の Default

ある製品開発で管理画面を作ることになりました。その際にフロントエンドの技術に疎いプロジェクトマネージャーが技術選定から始める必要がありました。基本的に誰がやっても技術選定は難しいです。選定の成否は決めた時点では分からないからです。フロントエンドに詳しいメンバーがチームにいれば委譲したり、メンバーがなんらかの技術に精通していればその技術を選択するという考え方もあります。しかし、残念ながら、私たちのチームではそういう状況にありませんでした。そこで覚悟を決めて、分からないなら分からないなりに1から調査して技術選定を行うことにしました。本稿では、主に次の内容について説明します。どのように技術選定を進めたか どのような調査を行ったか 最終的にどういう視点で技術を選定したか 昔ながらのテンプレートを使ったサーバーサイドレンダリングは生き残れるか 私が引き継ぎをうけたとき、前任者がプロトタイプとして実装していた管理画面の要素技術は次の2つでした。text/template UIkit go 言語で実装した http サーバーのサーバーサイドで html のテンプレートをたくさん書き、コンポーネントに UIkit を使ってプロトタイプ実装していました。私は UIkit についてよく知りませんが、一昔前は私も同じような構成でテンプレートと jQuery でシンプルな管理画面を作ったりしていました。jQuery 本体の開発はまだ続いていますし、後述する Stack Overflow の調査でも少なくない割合の開発者がまだ利用していることも確認できます。しかし、私は最初からこの旧来のやり方を踏襲してフロントエンド開発を進めることは考えていませんでした。それは次の理由からになります。最近のフロントエンド開発において主流のスタイルではない 新しい開発スタイルを取り入れて他プロジェクトでも再利用できるようにしたい メンバーが新しい技術や知識を学ぶきっかけにしたい 単純に旧来のやり方を否定しているというわけではなく、新規開発におけるプロダクトの保守コスト、メンバーの育成や採用なども考慮しました。総合判断としてもモダンなフロントエンド開発の技術に挑戦する方がよいだろうと考えました。定例ミーティングで既存のプロトタイプを引き継がないことを共有して承認を得たものの、流行りのフロントエンド技術として何を

はじめに mod_auth_mellon は複数のIdPと連携することが出来ます。今回は複数IdPと連携する手順を解説します。私は以前mod_auth_mellonを使ってみたという 記事を書きましたが、このときは IdP は一つでした。 IdP が一つの環境では未認証の状態で mod_auth_mellon にアクセスすると IdP にSAMLリクエストを送ります。mod_auth_mellon が複数のIdPと繋ぐ場合 複数のIdPと繋ぐ場合、mod_auth_mellon はユーザーがアクセスしてきた際にどの IdP に SAMLリクエストを送れば良いかわかりません。 そのため一度ディスカバリーサービスに遷移させ、ディスカバリーサービスでどの IdP を利用するか決めてもらい、 mod_auth_mellonはディスカバリーサービスで決まった IdP へSAMLリクエストを送るというシーケンスになります。このようにmod_auth_mellonで複数の IdP と連携する場合はどの IdP にSAMLリクエストを送るかを決めてもらうディスカバリーサービスが必要です。 ディスカバリーサービスは何らかの手段で利用する IdP を決め、 mod_auth_mellon に戻す機能が必要となります。ディスカバリーサービスを提供するプロダクトとして Shibboleth Discovery Service がありますが、 必ずしもアプリケーション環境を準備しなくても利用可能です。 本記事では単純な HTML の Form タグで IdP のリスト画面を表示し、ユーザーにIdPを決めてもらう構成で構築します。構成 複数IdPと連携する構成を示します。mod_auth_mellon(SAML SP) OpenAM(IdP1) Shibboleth IdP(IdP2) ディスカバリーサービス(ただのHTMLファイル) 一つの mod_auth_mellon で OpenAM と Shibboleth IdP の２つの IdP と連携するシステムを構築します。 事前準備として mod_auth_mellon は構築済みで、個別に一つの IdP としてOpenAM と Shibboleth IdP とは連携が出来ている状態とします。

はじめに 2021年9月に学認Shibboleth IdP構築技術ガイドの問題として公開された内容を解説します。【注意喚起】 学認Shibboleth IdP構築技術ガイドJetty版の設定例の問題につきまして https://www.gakunin.jp/ml-archives/upki-fed/msg01425.html Jetty にはクライアントIPアドレスを通信の接続元ではなくリクエストHTTPヘッダーから取得する http-forwaded モジュールがあります。 これは構成を把握して利用しないと偽装されてしまう可能性があります。 Jettyに限らず、socket以外からIPアドレスを取得する場合は仕様を把握して使いましょうというお話です。構成 問題を把握するためIPアドレスを表示するJSPを配置して何が起こるのかを解説します。Apache + Jetty の構成 Apache で 443(HTTPS) を Listen Jetty で 8080(HTTP) を Listen 検証のため意図的に Jetty は 0.0.0.0:8080 でListenし、別のサーバーからもアクセス可としています。 Jetty は 9.4.48.v20220622 で検証しています。 Apache では ProxyPass で Jetty に HTTP通信で接続します。 ProxyPass / http://127.0.0.1:8080/ Webアプリケーション JettyにクライアントIPアドレスを表示する JSP を配置します。 <%@ page contentType="text/html; charset=UTF-8"%> <html> <head><title>GET IP</title></head> <body> ipAddress:[<%=request.getRemoteAddr()%>] </body> </html> サーバーのIPアドレスは 192.168.48.2 利用者のIPアドレスは 172.16.17.21 この構成で利用者が「Apache経由でJSPにアクセス」、「直接Jettyにアクセス」ではJSPの結果で表示される画面のIPアドレスは次のとおりです。Apache経由 -> 127.

1. はじめに 上司やお客様から突然「スマホアプリも認証サーバ（Webベースのシングルサインオン系）と連携して」と言われた場合、どうしますか？ まずはWeb上で情報を探す、、、としても、シングルサインオンの分野はアプリ開発自体に比べると関わっている人が少なく、情報が中々見つけづらいものかなと思います。というところで本記事では、おすすめ実現案やら試してみた結果やらを書いてみます。 もし記事をお読みくださったら、認証系製品（認証サーバ＆クライアント側モジュール製品）のベンダ候補として、弊社（OSSTech株式会社）も加えていただけますと嬉しいです。2. おすすめ実現案 さて、、どんな感じでスマホアプリでも認証サーバと認証連携できるようにしましょうか。多くの場合、認証サーバ（シングルサインオンサーバ）は、複雑＆多様な認証を実施できるようなWebインタフェースを用意してくれてます。そして、スマホの方ではアプリ本体とブラウザとを連携する仕組みがあります。これら状況を踏まえ、『アプリ本体とブラウザとを連携させ、ブラウザから先は普通のWebアプリの認証連携と同じにする』という実現案をおすすめします。 （凄く凄く頑張れば、スマホアプリのコード内にて認証画面を実現して認証サーバとの通信を制御して…、なんてこともできるのかも知れませんが。。コスト的にもセキュリティ的にも、そちらはお勧めしません。）『スマホアプリとブラウザとを連携させ、ブラウザから先は普通のWebアプリの認証連携と同じにする』を図にすると、以下のようなイメージです。なお、弊社（OSSTech株式会社）で扱っている製品名も例示しています;-)そもそも普通のWebアプリの認証連携とは…？については、過去記事群（特にこちら）にて記していますので、必要に応じてお読みいただければ幸いでございます。3. 試してみた 理屈としては上記のような案で実現可能、、とは思いつつ実際試してみたことはなかったので、今回試してみました。 スマホ上でのアプリ／ブラウザ連携にはいくつか方法があるようなので、いくつかメジャーなパターンと思われるものをピックアップして試してみます。結果はこんな感じです。# 試したパターン FIDO2/WebAuthn対応 ブラウザからアプリへの戻り方 備考 1 iOS x アプリ"上"ブラウザ（WKWebView） × プ

はじめに OpenLDAP 2.5の新機能となるlloaddの機能について紹介します。lloaddは、LDAP用のロードバランサーとして実装されたOpenLDAPのモジュールで、受け取ったLDAPリクエストを複数のLDAPサーバーに振り分けて、LDAPサーバーの負荷分散を行うことが可能です。lloaddとマルチマスターのLDAP2台を組み合わせた場合の処理の流れは下図のようになります。lloaddの設定 今回は1号機をロードバランサー、2号機と3号機でマルチマスター構成にします。OpenLDAPの1号機はlloadd機能のみを利用するために、 1号機のslapd.confに下記のパラメーターを設定します。本記事ではbackend-serverに2号機と3号機の2台のLDAPサーバーを指定していますので、 1号機のロードバランサーは2号機と3号機にリクエストを振り分けるようになります。slapd.confmoduleload lloadd.la backend lload # The Load Balancer manages its own sockets, so they have to be separate # from the ones slapd manages (as specified with the -h "URLS" option at # startup). listen "ldap://:1389" # Enable authorization tracking feature proxyauthz # Specify the number of threads to use for the connection manager. The default is 1 and this is typically adequate for up to 16 CPU cores.

サーバーセットアップ インストールメディアの作成 書き込みソフトのインストール etcherをインストールします https://www.balena.io/etcher/インストールディスクをダウンロードarchlinux-x86_64.iso をダウンロード https://ftp.jaist.ac.jp/pub/Linux/ArchLinux/iso/latest/ etcher で、インストールイメージをUSBメディアに書き込みます。 etcherの操作 Flash from file からダウンロードしたISOファイルを選択 USBドライブを選択 flash を選択 終了したらドライブをサーバーに挿してUSBブート 今回のサーバーは起動時にDEL連打でUEFIシェルに入れました UEFIシェルの設定 Secure boot を無効化します Arch Linuxのインストール パーティション構成 OSSTechでは、ドライブを暗号化することになっているので、パーティションの暗号化も行いますEFIブートパーティションは暗号化されません EFIパーティション(/boot配下)にパスワード等の重要なファイルを置かないように気をつけてください。 LUKS on LVM でファイルシステムを構成します ブロックデバイスを暗号化してからLVM（論理パーティション）を作成します パーティションレイアウト パーティションは以下のように構成しますSSD 容量 パーティション 512MB /boot (EFI) 残り / HDD 容量 パーティション すべて /vault SSDのフォーマット gdiskを利用し、パーティションを作成しますgdisk /dev/nvme0n1 既存のパーティションをすべて削除します。Command (? for help): d No partitions GPT でパーティショニングします。MBRは2TBまでしか認識できないので、今どきはGPTでパーティショニングする必要があります。Command (? for help): o This option deletes all partitions and creates a new protective MBR.

はじめに OpenLDAP 2.4とOpenLDAP 2.5のログの差分について紹介します。OpenLDAP 2.4までのログと比較すると、bind_ssfと時間情報が追加されています。検証環境 OpenLDAP 2.5(AlmaLinux 9.0)OpenLDAP 2.4(CentOS 8)ログの比較 OpenLDAP 2.4とOpenLDAP 2.5を用意して、LDAP操作後のログを比較しました。検証環境のloglevelはstatsです。bind_ssf、qtime、etimeが追加されています。bind_ssfbind方式のssf1qtime操作が行なわれるまでキューに入っていた時間etime操作の処理時間qtimeとetimeのイメージ図を下図に示します。各リクエストを実行した際にOpenLDAP 2.4とOpenLDAP 2.5が出力するログの形式を掲載します。bind OpenLDAP 2.4BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 RESULT tag=97 err=0 text= OpenLDAP 2.5BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=0 RESULT tag=97 err=0 qtime=0.000004 etime=0.000031 text= ldapsearch OpenLDAP 2.4SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=testuser)" SEARCH RESULT tag=101 err=0 nentries=1 text= OpenLDAP 2.5SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=testuser)" SEARCH RESULT tag=101 err=0 qtime=0.

0. はじめに 上司やお客様から突然「Webアプリを認証連携（SAML／OpenID Connect）対応して」と言われた場合、どうしますか？いずれ弊社（OSSTech株式会社）のような専門ベンダに連絡するとしても、その前に、ベースの知識を得ておくためにWeb上で情報を探してみるのではないでしょうか。認証連携（SAML／OpenID Connect）の仕様については既に多くのウェブページで解説されてますが、実現のための検討観点についてはあまり情報がないかも…という印象です。というところで本記事では、Webアプリを認証連携（SAML／OpenID Connect）対応されるエンジニアの皆様を意識し、検討時にベース知識を得るための情報源となるべく執筆します。もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。1. そもそも認証連携（Federation）とは？ 「認証サーバによってユーザが認証されたら、アプリとしても認証済みとして扱うよう連携する」、ということです。認証連携のための標準仕様として SAML や OpenID Connect があり、既に広く普及してきています。１つの認証サーバに対して複数のアプリを認証連携で繋げた場合、そのシステム全体はシングルサインオン環境となります。シングルサインオンの文脈で既に解説している記事シリーズを書いていますので、必要に応じてご参照ください。（突然「シングルサインオン（ＳＳＯ）を検討して」と言われたら 第１回、第２回、第３回、第４回、第５回）Webアプリを認証連携対応することで、大きくは以下のようなメリットを享受できます。# 項目 説明 1 認証の強化 アプリ自体で認証方式を様々用意しなくても、連携先の認証サーバを利用することで、多要素認証などの強固な認証を利用できる。 2 販売機会増 標準仕様（SAML, OpenID Connect）での認証連携接続を前提としたシングルサインオン環境が普及しており、これが受注要件であった場合に販売機会を得られる。 2. 検討項目 認証連携対応を実施すると決まったら、どのように検討を進めたら良いでしょうか。大枠としては、以下のような項目を検討する必要があります。検討が難しい項目もあるかもしれませんが、ざっくりとでも予め検討しておくと、その後弊社のような専門ベン

はじめに 社内用にコーヒー粉がありますが、難易度が高いという問題が報告されているため、マニュアル化を行い品質の均一化を図ります。道具の所在 コーヒー粉はキャニスターに入れて保管されています。赤い缶を開けて利用してください。ドリップ用ペーパーはポットの近くにありますが、なくなっていた場合流しの上の棚の一番上の段にあります。準備 コーヒーデカンタ（一旦溜めとくポット）、コーヒーカップ、ドリッパーを洗います。 ポットに水を入れ、お湯を沸かします。ポットの水位線まで水を入れてください。 この水はコーヒーを入れるのに利用しないため、必ず水道水で行ってください。 コーヒーデカンタの上に、コーヒードリッパーをセットします。ペーパーの端の接着されている部分（「/////」のようになっている箇所）を折り、ドリッパーにセットします。セットする際、折りたたまれている部分を逆向きに折ることで開き、ドリッパーにフィットするよう曲げます。 メタルフィルターを利用する場合、ドリップペーパーは不要です。 ドリッパーにセットされたペーパーフィルターにコーヒー粉を入れる前に、紙に沸かしたお湯をすべてそそぎます。紙の保管状態が万全でないため、熱湯消毒や汚れ落としのため必要です。 新たにコーヒーを入れる用のお湯を沸かします。コーヒーカップに、ドリッパーと紙のセットを移し、コーヒーデカンタに溜まったお湯を注ぎます。器具の温度を上げることと、熱湯消毒が目的です。 お湯が落ちきったら準備完了です。コーヒーのドリップ 準備の手順で、空になったコーヒーデカンタにドリッパーをセットし、コーヒー粉を入れます。150mlあたり計量スプーン1杯が標準量です。気分に応じて増減させてください。 ドリッパーを横から小突き、粉を平らにします。お湯が側面に当たるとそのままペーパーフィルターを通過し、お湯が混ざるため、平らに均して側面にお湯が行きにくくします。 くぼみを作る場合、やりすぎるとお湯が当たらない粉ができ、分量より薄くなるので注意してください。 正確にコーヒーを入れる場合、タイマーを開始しドリップにかける時間を均一化します。お湯をドリッパーの側面に接しない程度に注ぎます。蒸らす場合、このタイミングで20秒程度待ちます。蒸らした場合、粉の状態が安定し、日が経っていていても出来が安定しやすいです。作りたい濃さに応じて、ドリッパー

はじめに Lasso の脆弱性はSAMLアサーションが複数存在した時の署名検証の不備でした。 OpenAM は Lasso を使っていませんので Lasso の脆弱性は当てはまりませんが、 SAML の SP として動作することが出来ます。 OpenAM の実装としてSAMLアサーションが複数送られてきた場合どのような挙動(仕様)なのかを調べてみました。結論 OpenAMには Lasso の脆弱性(CVE-2021-28901)にあたる問題はありませんでした。OpenAM はSAMLアサーションが複数送られてくることを許容する 複数送られてきたSAMLアサーションの全ての署名を検証する 一つでも「署名されていない」「署名の検証に失敗」すればエラーとする 複数のSAMLアサーションが存在しても、使用するアサーションは一つ 最初に有効と判定したアサーションのみを使ってアカウントのマッピングを行う 検証内容 以下の内容の検証を実施しました。OpenAM を SAML SP として構築(SAML2認証モジュールを使用) SAMLアサーションが2つ存在するSAMLレスポンスを受けった場合のOpenAMの挙動を確認する パターン1 -> 署名あり、署名なしの順 パターン2 -> 署名なし、署名ありの順 パターン3 -> 署名あり、署名ありの順 パターン1,パターン2のケース どちらも Federation ログに以下のエラーが出力されて認証失敗となりました。libSAML2:06/10/2021 07:27:40:748 AM UTC: Thread[https-jsse-nio-8443-exec-9,5,main]: TransactionId[ffdf7b49-66f5-4463-ac45-32022fb927b5-1587] ERROR: SAML2Utils.verifyResponse:WantAssertionsSigned is true but some or all assertions are not signed パターン3 OpenAMでエラーとならず、認証に成功しました。ソースコードで確認する 検証で実際の動作は確認出来たので、ソースコードでも確認してみます。 コードは該当箇所のみ抜粋します。全部を見たい方はOpenAMコンソーシアムのソースコードで

はじめに 先日 Lasso の脆弱性CVE-2021-28091が公開されました。 Lasso は SAML などのフェデレーションプロトコルを実装したライブラリで、SAML SP として動作するApacheモジュールの mod_auth_mellon はこのライブラリを使用しています。 Lasso で見つかった脆弱性が mod_auth_mellon で影響するか確認した所、脆弱性を突いた攻撃は成立しないことがわかりました。 どうして攻撃は成立しないのか解説します。Lassoの脆弱性CVE-2021-28091 今回発見された Lasso の脆弱性は次のように公開されています。Fix signature checking on unsigned response with multiple assertionsWhen AuthnResponse messages are not signed (which is permitted by the specifiation), all assertion’s signatures should be checked, but currently after the first signed assertion is checked all following assertions are accepted without checking their signature, and the last one is considered the main assertion.

はじめに IIS に Shibboleth SP をインストールする手順を紹介します。IIS 上に環境変数を表示するコンテンツを準備して、 Shibboleth SP でそのコンテンツを保護対象とします。 IdP で認証完了したらコンテンツにアクセス可能となり、 IdP から受け取った値を表示することを実現します。環境および前提事項 Windows 2019 Server の IIS を使用 IIS はインストール済みで HTTPS でアクセス出来るようにしておきます。 「役割の追加」で「アプリケーション開発」の 「.NET」 を選択しておきます。 この記事では https://win2019.example.co.jp/ で IIS にアクセス出来る構成です。 自分の環境で実施する際は win2019.example.co.jp を読み替えて実施ください。 Shibboleth SP V3 を使用 SAML の IdP は構築済み Shibboleth SPと連携する SAML IdP は構築済みとします。 この記事では OpenAM を SAML IdP とします。 事前準備 事前準備として環境変数を表示するコンテンツを準備します。secureフォルダにファイルを作成 IIS のドキュメントルート直下に secure というフォルダを作成し、 ディレクトリ内にenv.aspxという名前のファイルを作成します。ファイルの中身は以下のようにします。<% @ Page Language="C#" %> <html><body> <% Response.

0. はじめに 上司やお客様から突然「多要素認証／二要素認証を検討して」と言われた場合、どうしますか？ いずれ弊社（オープンソース・ソリューション・テクノロジ株式会社）のような専門ベンダに連絡するとしても、その前に、ベースの知識を得ておくためにWeb上で情報を探してみるのではないでしょうか。多要素認証／二要素認証の基本的な考え方については既に多くのウェブページで解説されてますが、実現のための検討観点についてはあまり情報がないかも…という印象です。というところで本記事では、SE様のように多要素認証／二要素認証を導入なさる側の皆様を意識し、 導入検討時にベース知識を得るための情報源となるべく執筆します。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。1. 検討観点１：どのような多要素認証にするか 多要素認証の一要素目は従来と同様パスワードによる認証だとして（必ずしもパスワードでなくてもよいですが。）、二要素目としてどのような認証を実現すると良いでしょうか。弊社OpenAMで既に用意されているものから代表的なものを挙げるだけでも結構あります。# 二要素目認証に使えるもの 説明 1 クライアント証明書による認証 あらかじめユーザ端末にクライアント証明書を入れておき、認証時にユーザ端末から認証サーバへクライアント証明書＆署名が送付される。認証サーバは証明書＆署名を検証することで正しいユーザであることを確認する。 2 送付されたワンタイムパスワードで認証（SMS, LINE, email） ユーザが所有するSMS, LINE, emailアカウント宛てに、認証サーバがワンタイムパスワードを送付する。このワンタイムパスワードの入力をもって正しいユーザであることを確認する。 3 ワンタイムパスワード生成器と連動した認証 ハードウェアまたはソフトウェア（Google Authenticatorなど）のワンタイムパスワード生成器をユーザに所持してもらい、生成用の鍵を認証サーバとあらかじめ共有しておく。生成器に表示されたワンタイムパスワードの入力をもって正しいユーザであることを確認する。 4 FIDO2/WebAuthn（HOT!!） FIDO2仕様に準拠したデバイス（Windows, Android, iOS, 専用USBデバイス, etc...）

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===1.1 前回までのあらすじ 本記事シリーズでは、SE様のようにシングルサインオン(SSO)を導入なさる側の皆様を意識し、 SSOのベース知識を得るための情報源となるべく執筆していきたいと思います。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。第１回 本シングルサインオン解説シリーズの位置づけ なぜシングルサインオン化すべきか 第２回 シングルサインオン化のための大まかな要件定義 第３回 シングルサインオンの仕組みの代表的な例 第４回 認証方法の種類や選択検討 1.2 今回のお題 今回は、「アプリとの認証連携方法の種類や選択検討」について記していきます。2. アプリとの認証連携方法の種類 2.1 認証連携方法とは 本記事シリーズの第２回にて大まかな要件定義について書いてましたが、この3点目がアプリとの認証連携方法でした。 以下は、第２回の図の再掲です。アプリとの認証連携方法とは、「アプリをシングルサインオンの対象とするために行う、SSOサーバとの連携接続の方法」ということです。以下、代表的な認証連携方法として「標準仕様に基づく認証連携」「エージェントによる認証連携」「代理認証による認証連携」に分けて記していきます。2.2 標準仕様による認証連携 アプリとSSOサーバ間の認証連携方法には、SAMLやOpenID Connectといった標準仕様が定められたものがあります。動作としては、本記事シリーズの第３回のフロー図で記したものが代表例です。標準仕様の認証連携を行うにあたっては、アプリ側が標準仕様に応じた動作をする必要があります。 現在は各種言語のライブラリやApacheモジュールなどが利用できるため、敷居は高くありません。2.3 エージェントによる認証連携 標準仕様による方法以外にも、SSOサーバベンダから提供されるエージェントをアプリ側に組み込むことで、認証連携を実現できることがあります。 （アプリに成り代わってSSOサーバと連携するので、エージェントによる連携方法と呼ばれます。）大枠の動作としては、標準仕様に基づく認証連携の場合と変わりありません。なお、エージェントをアプリサーバに組み込む場合を「エージェント方式」と呼び、別のサーバにエージェン

Shibboleth IdP でのスクリプトによる属性生成 概要 Shibboleth IdP では、SPへの属性送出の際、スクリプトによる生成機能があります。 公式のドキュメントはありますが（https://wiki.shibboleth.net/confluence/display/IDP4/ScriptedAttributeDefinition）、ドキュメントをみても肝心のJavascriptエンジン部分に対する説明がなく、使い方がよくわかりません。 今回は、スクリプトによる生成を行う際の、処理の記載方法について記載します。設定箇所 attribute-resolver.xmlで指定します。※ attribute-filter.xml でもスクリプト処理を組み込むことができますが、こちらは送出の制限を組み込むべき定義であるため、送出属性の生成処理はattribute-filter.xmlに記載するべきではありません。設定方法 送出する際の属性名の指定 以下の行で、送出する属性の属性名を指定します。 今回の場合は、“eduPersonPrincipalName” の値を生成する指定です。<AttributeDefinition id="eduPersonPrincipalName" xsi:type="ScriptedAttribute"> ... </AttributeDefinition> スクリプトの処理であることは、「xsi:type」に"ScriptedAttribute"を指定することで指定します。生成の際に元にする値の指定 以下の行で、入力属性の属性名を指定します。以下の指定の場合、「ref=“myLDAP”」でデータストアで指定された “myLDAP” のデータベースからの情報取得を行います。<InputDataConnector ref="myLDAP" attributeNames="eduPersonPrincipalName uid" /> attributeNamesでは、指定したデータストアから取得する属性の値をスペース区切りで指定します。 今回の場合は、データストア上の"eduPersonPrincipalName", “uid"が取得されます。値の生成処理の指定 スクリプト処理の記載方法 実際の処理は以下のように記載します。処理部

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===1.1 前回までのあらすじ 本記事シリーズでは、SE様のようにシングルサインオン(SSO)を導入なさる側の皆様を意識し、 SSOのベース知識を得るための情報源となるべく執筆していきたいと思います。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。第１回 本シングルサインオン解説シリーズの位置づけ なぜシングルサインオン化すべきか 第２回 シングルサインオン化のための大まかな要件定義 第３回 シングルサインオンの仕組みの代表的な例 1.2 今回のお題 今回は、認証方法の種類や選択検討について記していきます。2. 認証方法の種類 2.1 認証方法とは 本記事シリーズの第２回にて大まかな要件定義について書いてましたが、この2点目が認証方式でした。 以下は、第２回の図の再掲です。認証方法とは、「アクセスしてきたユーザが確かにそのユーザであることを認定するための方法」ということです。 認証方法には様々なものがあり、以下に「個別の認証方法」「SSOサーバ間連携による認証」「認証方法の組み合わせ利用」に大別して記していきます。2.2 個別の認証方法 認証方法は、旧来からのID/Passwordによる認証から、最新のFIDO2/WebAuthnまで、様々なものがあります。 以下、代表的な認証方法を記します。# 認証方法 説明 備考 1-1 ID/Password ID/Passwordの入力による認証を実施。 - 1-2 ワンタイムパスワード：送付型 別ルートでユーザにワンタイムパスワードを送付し、その入力による認証を実施。通常、ID/Passwordの認証と組み合わせて利用される。 別ルートとしては、email、SMS、LINE等がある。 1-3 ワンタイムパスワード：生成器連動型 ユーザが保持しているワンタイムパスワード生成器と連動し、生成されたワンタイムパスワードの入力により認証を実施。通常、ID/Passwordの認証と組み合わせて利用される。 生成器としては、Google Authenticator等のスマホアプリや専用小型デバイスがある。 1-4 Windows統合認証（DesktopSSO） Active DirectoryやSambaによって組織内

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===1.1 前回までのあらすじ 本記事シリーズでは、SE様のようにシングルサインオン(SSO)を導入なさる側の皆様を意識し、 SSOのベース知識を得るための情報源となるべく執筆していきたいと思います。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。第１回 本シングルサインオン解説シリーズの位置づけ なぜシングルサインオン化すべきか 第２回 シングルサインオン化のための大まかな要件定義 1.2 今回のお題 今回は、シングルサインオンの仕組みの代表的な例、について書いていきたいと思います。2. シングルサインオンの仕組みの代表的な例 2.1 なぜ理解しておくべきか 本記事シリーズの第１回から、「シングルサインオン化のためには、SSOサーバを導入し、 各アプリがSSOサーバと認証連携することで実現する」という形の図を出していました。 以下は、第１回の図の再掲です。ただ、一言で「認証連携」と書いてきましたが、どのような仕組みで実現されているのでしょうか。 この全体的な仕組みを知らないままですと、SSOサーバのベンダとの会話の効率や、 個別技術要素の理解の効率が悪くなってしまったりするかもしれません。そこで今回は、シングルサインオン実現のための仕組みについて、代表的な例を記していきたいと思います。 （実際はいくつかの仕組みがありますが、１つ代表的な例を知っておくことで、他の仕組みも理解しやすくなると思います。）2.2 シングルサインオンの仕組みの代表的な例 シングルサインオンの仕組みの代表的な例について、以下の簡易シーケンス図にて記していきます。[1] ユーザがWebアプリＡを使うため、ブラウザを用いてアプリＡのURLでアクセスします。[2] アプリＡは、ブラウザから送付されてきたCookieなどからアプリＡとしての認証状態をチェックし、まだ認証済みでなければSSOサーバへリダイレクトします。 （リダイレクトではなく、同等の「自動POSTするコンテンツ」を返すこともあります。）[3] SSOサーバは、ブラウザから送付されてきたからCookieなどからSSOサーバとしての認証状態をチェックし、まだ認証済みでなければ認証画面を返します。 （ここではID/PWの入力

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===1.1 前回までのあらすじ 本記事シリーズでは、SE様のようにシングルサインオン(SSO)を導入なさる側の皆様を意識し、 SSOのベース知識を得るための情報源となるべく執筆していきたいと思います。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。第１回 本シングルサインオン解説シリーズの位置づけ なぜシングルサインオン化すべきか 1.2 今回のお題 今回は、大まかな要件定義について書いていきたいと思います。2. シングルサインオン化のための大まかな要件定義 詳細な要件定義については、SSOサーバのベンダ(弊社のような！)を呼んでからの実施でも良いと思います。 しかしその前に、大まかな要件について予め確認できていると、以後の専門ベンダとの会話もスムーズになります。 （要件に合わないベンダを呼んでしまってお互い不幸な時間を過ごしてしまう、、なんていうリスクも減らせます。）SSOの要件を検討するにあたっては、複数の要素が絡み合って、纏めることが難しい場合もあるかもしれません。 が、ここではひとまず大まかに要件を把握すると割り切り、「ユーザ」「認証方法」「アプリとの認証連携方法」という３つの視点に大別してざっくり検討する、という想定で書いてみます。[1] ユーザ 「ユーザ」という視点の要件定義項目として、以下のようなものが考えられます。# 項目 説明 備考 1-1 ユーザの種類 「社内ユーザ／社外ユーザ」「ユーザの所属グループ」というようなユーザの種類のことです。例えば、既存アプリ群でID体系が異なっている場合は、名寄せ後の制御などを検討する必要があります。また、ユーザの種類に応じて利用できるアプリが異なる場合は、認可制御を検討する必要があります。 どのような制御が可能かはSSOサーバ製品毎に異なってきますので、まずは存在するユーザ種類を把握した上でSSOサーバのベンダと会話するのが良いです。 1-2 アクティブユーザの人数 最大でどの程度の人数のユーザがログインする可能性があるのか、という点です。 SSOサーバのメモリ容量といったサイジングに影響します。 1-3 スループット 最大でどの程度のスループットを処理できる必要があるのか、という点です。 サーバ

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===1.1 本記事シリーズの位置付け 上司やお客様から突然「シングルサインオン(SSO)を検討して」と言われた場合、どうしますか？ いずれ弊社（オープンソース・ソリューション・テクノロジ株式会社）のような専門ベンダに連絡するとしても、 その前に、ベースの知識を得ておくためにWeb上で情報を探してみるのではないでしょうか。シングルサインオン(SSO)という分野は、アプリ開発の分野に比べると関わっている人が 少ないということもあり、初めての人向けの纏まった＆最新化された情報というのは 中々見つけづらいものかな…と思っています。 少なくとも、私がシングルサインオンを扱い始めた際は、わりと苦労しました。というところで本記事シリーズでは、SE様のようにシングルサインオンを導入なさる側の皆様を意識し、 ベース知識を得るための情報源となるべく執筆していきたいと思います。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。1.2 今回のお題 まずは何より、お客様や社内の皆様に意義を語る必要があったりしますよね。 というわけで、この第１回目の記事では、なぜシングルサインオン化すべきかについてざっくり書いてみます。2. なぜシングルサインオン化すべきか Before ⇒ After の形で、なぜシングルサインオン化すべきかを書いてみます。2.1 Before（シングルサインオン化されていないと…） シングルサインオンする前の姿、つまりユーザが各アプリケーションへ個別にサインオンする形は、様々な視点で問題があります。# 視点 内容 1 ユーザビリティ アプリ毎にログイン作業をするのはユーザにとって負担になる。アプリ毎に異なるパスワードポリシだったりするとさらに辛いことに…。 2 セキュリティ アプリケーション毎にログイン処理を開発した場合、その分セキュリティ脆弱性の存在可能性も増えてしまう。仮に１つのアプリの脆弱性でパスワードが漏洩し、それが他アプリへのリスト攻撃の引き金になったりすると酷い状況に…。 3 コスト アプリケーション毎にログイン処理を開発した場合、その分開発やメンテナンスコストがかかる。上記したようなセキュリティ問題を発生させないための開発・テストのためには高い

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===前回記事では、.NET／Visual BasicでLDAPクライアントプログラミングをする場合の事前準備やコード例を記しました。 今回はJava編を書いていきます。2. 準備するもの Javaの開発環境…は当たり前なので詳述しません。LDAPに直接関連して事前準備すべきもの…については、前回記事にて記載しましたのでそちらを参照してください。（今回も同じLDAP情報を事前入手した、という仮定とします。） ここで、LDAPS時の証明書が止むを得ず自己署名証明書だったりした場合は、Javaのトラストストアに証明書を格納して、Javaプログラム実行時にそのトラストストアを参照するよう設定してください。3. LDAPクラアイントプログラミングしてみる 前回記事で書いた .NET／Visual BasicでLDAPデータを読み書きするコードを、Javaに移植してみます。3.1 プログラム JavaでLDAPクライアントプログラミングするにあたり、標準ライブラリだけで見ても javax.naming.directory 系と javax.naming.ldap 系が存在します。どちらを使っても実現できますが、今回は前者を使うことにします。 さて、ごりごりっとコード書きましょう。こんな感じ。// 本記事ではimport分は省略します public class LDAPClientTest {public static void main(String[] args) throws NamingException { //------------- // Connect //------------- Hashtable<String, String> env = new Hashtable<String, String>(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, "ldaps://ldapserver.mydomain.test:636"); env.put(Context.SECURITY_AUTHENTICATION,

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===弊社オープンソース・ソリューション・テクノロジでは、LDAPのサーバ側製品としてOpenLDAPを取り扱ってます。おかげさまで多くのお客様に導入いただき、ユーザ統合管理や統合認証の実現に寄与させていただいてます。 OpenLDAPを導入いただく際にお客様から時々ご質問いただくのが、「LDAPサーバ内のユーザ情報を読み書きするクライアントプログラムを開発したいのだけれど、どうしたら良い？」だったりします。 基本的には「LDAPは標準仕様ですので、仕様に準拠しているクライアントライブラリなどを利用して開発してください。」という回答になりますが…、LDAPクライアントプログラミングって多くの人が経験するものではなく、結果としてWeb上でも情報が少な目になってしまうので、突然担当することになってしまったら不安になってしまうかもしれません。しかし、実はやってみると案外スッと実現できるものなので、やってみた記事を書いてみることにします。いつか、どこかのSEさんが「あぁ、これくらいで動かせるんだー」と安心できる助けとなりますように。 今回は.NET編。次回はJava編ということで書いていきます。2. 準備するもの .NETの開発環境…は当たり前なので詳述せず、ここでは、LDAPに直接関連する事前準備について記します。 基本的に、全てLDAPサーバ側の管理者に問い合わせて情報を得るものです。[1] LDAPサーバ情報 「どうやってLDAPサーバに繋げばいいの？」の情報を得ておきます。 以下の情報が得られたと仮定します。項目 値 サーバ名 ldapserver.mydomain.test プロトコル（LDAP/LDAPS） LDAPS ポート 636 ここで、LDAPSのためのサーバ証明書が止むを得ず自己署名証明書であった場合は、 予め証明書を入手してLDAPクライアント機にインポートしておきましょう。[2] データ操作用アカウント情報 「どのアカウントを使ってLDAPサーバ上のデータ操作したらいいの？」の情報を得ておきます。 以下の情報が得られたと仮定します。項目 値 データ操作用アカウント名 cn=datamaster,dc=ldapserver,dc=mydomain,dc=test パスワード

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===OpenAM 13では、アクセスログや認証ログがCSV形式で出力されます。 プロジェクトによっては、ログに対して以下のような処理が必要とされる場合があります。ログ解析ソフトが読み取れる形式に前処理する必要がある。 特別な解析をしたい。 上記のような処理の実現は、弊社ではなくてシステム全体纏めのSIer様の領域ですが、「OSSのデータ処理ツールが既にいくつも存在するから、それを使えば楽なのでは…」と思う場面が何度かありましたので、こんな風にできるよという紹介記事を書いてみます。 今回取り上げるデータ処理ツールとしては、Pentaho DI（Data Integration）とします。2. 実施 2.1 前提など 前提として、弊社版のOpenAM 13のログを利用することとします。 また、今回実施したい処理のシチュエーションとしては、「各人が過去に何回ログインしたかを知りたい」とします。扱うログは、今回は認証結果を扱うので「authentication.csv」が対象となります。デフォルトでは、/opt/osstech/var/lib/tomcat/openam/openam/log/authentication.csv に出力されています。 データの内容は以下のようなもので、1行目にラベルがあり、2行目以降に認証の成否情報が出力されていきます。2.2 Pentaho DIのダウンロード＆インストール Pentaho DIは、以下のサイトからダウンロードして利用できるOSSです。 https://sourceforge.net/projects/pentaho/files/latest/download （Apache License 2.0） 今回は、バージョン8.1.0.0-365を利用します。Pentaho DI は Javaプログラムなので、パッケージとしてのインストールは必要なく、zipをダウンロードして展開するのみです。Java実行環境(JRE／Java Runtime Environment)は、別途インストールしておく必要があります。2.3 Pentaho DI（の処理設計ツール）を起動 zipを展開した中にあるspoon.sh（Windows環境ならSpoon.bat）

1. はじめに === この記事は、以前Qiitaに挙げていたものの再掲です ===新入社員のアカウントの初期パスワードは、どのように設定・入力してもらうと良いでしょうか。初期パスワードを設定する際、誕生日にアルファベットを足したものや社員番号など、類推可能なものにするのは危険です。ランダムな文字列にする場合でも、短いものにしてしまうと、ブルートフォースアタックの脅威にさらされてしまうかもしれません。それでは長いランダム文字列にした場合は…、今度は利用開始の障壁になってしまいそうです。解決案として、「長いランダム初期パスワードをQRコード化して送付し、初回ログイン時はQRコードをかざすことで認証してもらう。（その後、強制的にパスワードを変更してもらう）」、というのはどうでしょうか。幸い近年、QRコードを扱うJavascriptライブラリを公開してくださってる、素晴らしい方々がいらっしゃいます。弊社も取り扱っております認証基盤OSS「OpenAM」では色々カスタマイズが可能なので、ライブラリを組み込んでQRコード認証の実現を試してみます。（注： 本記事は、あくまで簡易的に試してみるというものです。実際にご利用される場合は、各自のご責任の下で実施くださいませ。）2. 実施 2.1 OpenAM のインストールと初期設定 まず、OSSTech版のOpenAM 13をインストールして初期設定しておきます。ここは今回の本題ではないので、詳細は割愛します。 （OpenAM 13がお手元にない場合でも、読み取ったQRコードの格納先となるテキストフィールドなりをご用意いただければ、QRコード読み取りのテストは可能です。）次にですが、スマホでもカメラを起動してＱＲコードを読めるようにするためには、httpsでのアクセスにする必要があるようです。このため、あらかじめhttps化の対応もしておきます。ここも、詳細は割愛します。ここでログイン画面にアクセスしてみると、OpenAMでは初期状態でデータストア認証の画面が出てくるようになってます。普通にIDとパスワードを入れるというものでして、画面例は下図のようになります。 これから、このパスワードのフィールドへの入力を、QRコード読み込み対応にしてみます。2.2 QRコード読み取りライブラリの取り込み QRコード画像を読み取るjavascri

Apacheの REQUEST_URI で勘違いしていた話 Apache設定時等に出てくる REQUEST_URI の値は QueryString が「含まれるケース」と「含まれないケース」があります。例えば次のようにアクセスしたときに REQUEST_URI の値は「/cgi-bin/env.cgi?test=1」「/cgi-bin/env.cgi」どちらなのかというお話です。http://www.example.co.jp/cgi-bin/env.cgi?test=1 具体的には次のとおりです。QueryString が「含まれるケース」 php や CGI で使用可能な Apache がセットした 環境変数REQUEST_URI 特に設定なし(デフォルト)の場合であり、Apache の設定により QueryString を含めなくすることも出来ます。 QueryString が「含まれないケース」 mod_rewrite で使用する %{REQUEST_URI} mod_setenvif で使用する %{REQUEST_URI} Ifディレクティブ などの expr で使用する %{REQUEST_URI} mod_ssl の環境変数(例: mod_headers では %{REQUEST_URI}s と指定して使用) 調べた経緯 ある時「アクセスURL の拡張子が mp4 以外のときだけに特定の処理を行いたい」という要件がありました。 Ifディレクティブ を使って以下のように出来そうです。<If "%{REQUEST_URI} !~ m!\.mp4$!i"> [やりたい処理] </IF> 私はこの設定の場合 QueryString が含まれたアクセスでは「Ifが真にならない」と思っていました。 しかし、実際に動作確認をしてみると QueryString が含まれたアクセスをしても If が真になり 要件を満たす動作になります。php で 環境変数REQUEST_URI を表示する 一方で CGI や php で Apache がセットする 環境変数REQUEST_URI を表示すると QueryString が含まれます。

検証環境 # cat /etc/centos-release CentOS Linux release 7.3.1611 (Core) # uname -r 3.10.0-514.el7.x86_64 疑問 KVMの手順で、ほとんどの場合特に何も説明せず書かれている「–extra-args=“console=tty0 console=ttyS0,115200n8r”」とは一体何なのか。結論 Linuxカーネルのシリアル接続用のパラメータ https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/serial-console.rstそもそもttyとは TeleTYpewriteのことで、標準入出力デバイスの事を指しています。 普段意識して使うことはあまりありませんが、機材にモニタを接続してのログイン、そして今回利用するシリアル接続でのログインの際に作成される、仮想端末の入出力に利用されています。仮想端末は、伝統的に横80文字、縦25列のコンソール画面です。取りうる名前の一式 仮想端末では以下の名称を利用します。(Xは数値)・ttyX ・ttySX ・lpX ・ttyUSBXtty0は今プロセスの実行ユーザーが接続している仮想端末に対するエイリアスです（つまり、利用している仮想端末が変わる可能性があります）。 ttyXは一般的なLinuxでは1~6の値が用意されており、コンソール画面で Alt+F1～F6 のボタンを押すことで利用することができます。 ttyの数は/etc/systemd/logind.confのNAutoVTsで制御可能です。 OSによってはグラフィカルログイン画面まで起動した状態からでも、Ctrl+Alt+F1～F6 のボタンを押すことで利用することができます。 ttyS(数値)はシリアル接続用の仮想端末です。また、lp0というパラレルポート用の仮想端末、ttyUSB0というUSB接続のシリアルデバイス用の仮想端末も用意されています。つまり、疑問の項のtty0 ttyS0は、仮想端末、シリアルデバイス用仮想端末に対して接続するという意味です。0はプロセスが利用している仮想端末ですが、この時点では定義されていないため、適当な空いているものを利用するという意味として扱わ

はじめに OSSTechブログはMarkdownで記事を書くことができてとっても技術者フレンドリーになっています。 私は非技術者で普段Markdownを使わないので、Markdownに慣れるための習作としてOSSTechの社員旅行のことでも書いてみようかと思います。本当は今年の社員旅行の旅行録的な記事を書くつもりだったんですが中止になったので。。1OSSTechの社員旅行 私は中途でOSSTechに入社していますが、これまでの会社で社員旅行というものを経験したことがありませんでした。社員旅行のイメージは『めんどくさそう』ではありましたが、元々旅行は好きだったのでまぁ楽しめるだろうと思っていました。その期待は大きく裏切られることとなります、良い意味で。OSSTech社員旅行のすごそうなポイント 上述の通り、他社の社員旅行を知らないので当たり前なことも含まれているかもしれないですが、すごいと感じたところを書いていきます。行先は社員が決めるOSSTech社員旅行の戦いは行先を決めるところから始まります。海外と国内を一年ごとに交互に繰り返すのはふんわりと慣例になっているようですが、行先については一切やらせなしの投票で決まります。有志で行きたいところとアピールポイントを記載して、社員が持ち票を投票します。一人あたりの持ち票は社長ですら平等なのです。 上図は去年の投票の様子です。（沖縄に決まりました）行先での旅程も概ね自由行先は決まっても社員旅行のイメージで旅先ではパッケージツアーが組まれていたりなどで自由に過ごせないようなイメージがありますが、OSSTech社員旅行はそうではありません。旅先での旅程も大部分は社員に裁量が与えられています。 沖縄旅行では全員で行動していたのは美ら海水族館に訪れた時だけで、他の時間は数人単位でまとまっていることが多いですが思い思いに過ごしています。海にマリンアクティビティしに行く社員も多くいましたが、私はゴルフしたり、地元の名店的なお店に行ってみたりとマイペースに楽しむことができました。割とグレードの高いホテルにとまる 私は個人旅行ではどちらかというとコストカットに走る傾向があるので、あまり使わないようなホテルに泊まれるのもテンションが上がります。 今ならgo toキャンペーンで行ける人もいるかもしれませんね。2まとめ OSSTechの社員旅行は

はじめに 会社ホームページの公開と合わせて、OSSTechブログを開設しました。 開設に至るまでの経緯や、ブログの内容について簡単にお知らせします。ブログ開設に至るまでの経緯 元々社員がブログ的な記事を投稿する場としては、Qiitaなどの他社サービスを活用していたりしたのですが、運用していくうちに以下のような課題が見つかりました。他社サービス利用の課題 発信できる情報の制限 弊社がブログ記事で発信したいことは大きく分けると以下の3つです。技術情報発信 採用活動 製品マーケティング、営業活動 他社サービスはその特性上、技術情報発信以外の記事投稿は難しいものもあり、 技術情報の発信にとどまっていました。運営母体に依存する運用 ナレッジコミュニティには色々なサービスがありますが、その時々によって最も見られているサービスは移り変わっていくものかと思います。 しかし、OSSTechとして発信したい内容がサービスの流行の移り変わりで見られる機会が減少するのは少し困ります。 さらに言うとそのサービス自体がクローズしてしまったら、そこに投稿していた記事も永遠に失われてしまいそれはとても困ります。 OSSTechブログの開設 ナレッジコミュニティからオウンドメディアへの切替は特にいいタイミングがなかったのですが、 会社Webページの改定に合わせて検討が進み、この度ブログ開設となりました。上でも触れていますが、技術情報の発信だけでなく、会社の雰囲気が伝わるような記事も投稿されていくと思います、暖かく見守っていただけますと幸いです。OSSTechブログを今後ともよろしくお願いいたします。