サービスレイヤーを使用してWebアプリケーションを構築しています。サービス層は、RESTfulデザインを使用して構築されます。将来的には、Webアプリケーションと同じサービスレイヤーを使用する他のアプリケーション(iPhone、Androidなど)を構築できると考えています。私の質問はこれです-ログインを実装するにはどうすればよいですか?もっと伝統的な動詞ベースのデザインからリソースベースのデザインに移行するのに苦労していると思います。 SOAP=を使用してこれを構築している場合、おそらくLoginというメソッドがあります。RESTリソースが必要です。ログイン用のURIを作成します。次のようになります。
http:// myservice / {username}?p = {password}
編集:フロントエンドWebアプリケーションは、認証に従来のASP.NETフレームワークを使用します。ただし、認証プロセスのある時点で、提供された資格情報を検証する必要があります。従来のWebアプリケーションでは、データベースルックアップを実行しました。しかし、このシナリオでは、データベース検索を行う代わりにサービスを呼び出しています。したがって、提供された資格情報を検証するサービスに何かが必要です。そして、提供された資格情報の検証に加えて、認証に成功した後のユーザーに関する何らかの情報(フルネーム、IDなど)が必要になる可能性があります。これにより、質問がより明確になります。
または、私はこれについて正しい方法を考えていませんか?質問を正確に説明するのが難しいと感じています。
コーリー
S.Lottが既に指摘したように、ここには2つの折りたたまれたものがあります:ログインと認証
認証は広く議論されており、共通の合意があるため、ここでは認証は範囲外です。ただし、クライアントがRESTful Webサービスに対して正常に認証されるために実際に必要なものは何ですか?そう、ある種のトークン、アクセストークンと呼びましょう。
クライアント)それで、私が必要とするのはアクセストークンだけですが、そのようにRESTfulに取得する方法は?
サーバー)単純に作成しないのはなぜですか?
クライアント)どうして?
サーバー)私にとって、アクセストークンはリソースに他なりません。したがって、ユーザー名とパスワードと引き換えに作成します。
したがって、サーバーはリソースURL「/ accesstokens」を提供して、ユーザー名とパスワードをPOSTし、新しく作成されたリソース「/ accesstokens/{accesstoken}」へのリンクを返します。または、アクセストークンとhrefをリソースのリンクとともに含むドキュメントを返します。
<access-token id = "{アクセストークンIDはここに入ります。例:GUID}" href = "/ accesstokens/{id}" />
ほとんどの場合、実際にアクセストークンをサブリソースとして作成しないため、応答にhrefを含めません。
しかし、そうする場合、クライアントはその代わりにリンクを生成できますか?番号!
RESTful Webサービスは、リソースリンクを生成することなくクライアントが自分自身をナビゲートできるように、リソースをリンクします。
最後の質問は、おそらくPOST HTMLフォームとして、またはXMLやJSONなどのドキュメントとしてのユーザー名とパスワード-それは依存します... :-)
「ログイン」しません。あなたは「認証」します。違いの世界。
認証の選択肢はたくさんあります。
HTTPベーシック、ダイジェスト、NTLMおよびAWS S3認証
HTTP基本認証およびダイジェスト認証。これはHTTP_AUTHORIZATION
ヘッダーを使用します。これは非常に素晴らしく、非常に簡単です。しかし、多くのトラフィックにつながる可能性があります。
ユーザー名/署名認証。 「IDとキー」認証とも呼ばれます。これにはクエリ文字列を使用できます。
?username=this&signature=some-big-hex-digest
これは、Amazonのような場所が使用するものです。ユーザー名は「id」です。 「キー」はダイジェストで、HTTPダイジェスト認証に使用されるものに似ています。両方の側がダイジェストについて同意する必要があります。
ある種のCookieベースの認証。 OpenAM は、たとえば、RESTful Webサーバーが使用できるCookieを認証および提供するエージェントとして構成できます。クライアントは最初に認証を行い、次に各RESTfulリクエストでCookieを提供します。
いい質問ですね。パトリックの答えが本当に好きです。私は次のようなものを使用します
-/ users/{username}/loginsession
POSTおよびGETが処理されます。したがって、資格情報を使用して新しいログインセッションをポストし、GETを介して現在のセッションをリソースとして表示できます。
リソースはログインセッションであり、アクセストークンまたは認証コード、有効期限などが含まれる場合があります。
奇妙なことに、MVCサイトはAPIのクライアントであるため、MVC呼び出し元自体がヘッダーを介してキー/ベアラートークンを提示し、新しいログインセッションを試行および作成する権利があることを証明する必要があります。
編集
ここでの他のいくつかの答えとコメントは、帯域外の共有シークレットで問題を解決し、ヘッダーで認証するだけだと思います。これは、多くの状況またはサービス間の呼び出しで問題ありません。
他の解決策は、トークンをフローすることですOAuthまたはJWTまたはそれ以外の場合、「ログイン」は別のプロセス、おそらくに基づいているブラウザの通常のログインUIによって既に行われていることを意味しますフォームPOST。
私の答えは、UIの背後にあるサービスに対するものです。ログインと認証、およびユーザー管理をRESTサービスではなく、サイトのMVCコードではなく、。ISユーザーログインサービス。
また、事前共有キーを使用する代わりに、他のサービスが「ログイン」して期限切れのトークンを取得できるほか、CLIまたはPostmanでテストスクリプトを使用できます。
RESTについて最初に理解することは、トークンベースのリソースアクセスです。従来の方法とは異なり、アクセスはトークンの検証に基づいて許可されます。現在、トークンの作成と操作には他にも多くのものがあります。
最初の質問については、Restfull APIを設計できます。資格情報(ユーザー名とパスワード)はサービスレイヤーに渡されます。サービスレイヤーはこれらの資格情報を検証し、トークンを付与します。資格情報は単純なユーザー名/パスワードまたはSSL証明書のいずれかです。 SSL証明書はOAUTHプロトコルを使用し、より安全です。
次のようにURIを設計できます-トークンリクエストのURI-> http:// myservice/some-directory/token ? (トークンのこのURIでCredentilalsを渡すことができます)
このトークンをリソースアクセスに使用するには、この[Authorization:Bearer(token)]をhttpヘッダーに追加できます。
顧客はこのトークンを利用して、サービスレイヤーのさまざまなコンポーネントにアクセスできます。このトークンの有効期限を変更して、誤用を防ぐこともできます。
2番目の質問でできることの1つは、サービスレイヤーのさまざまなリソースコンポーネントにアクセスするためのさまざまなトークンを付与することです。このために、トークンでリソースパラメータを指定し、このフィールドに基づいてグランドパーミッションを指定できます。
詳細については、これらのリンクをたどることもできます。 http://www.codeproject.com/Articles/687647/Detailed-Tutorial-for-Building-ASP-NET-WebAPI-REST
http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
2011年以降、かなりの変化がありました...
サードパーティのツールを使用して、RESTから少し離れたWeb UIの場合)から少し逸脱している場合は、 http://shiro.Apache.org を検討してください。
Shiroは基本的に、認証と承認を目的としたサーブレットフィルターを提供します。単純なフォームベースの認証を含む、@ S.Lottによってリストされたすべてのログインメソッドを利用できます。
認証が必要な残りのURLをフィルタリングすると、Shiroが残りを行います。
私は現在、自分のプロジェクトでこれを使用していますが、これまでのところかなりうまく機能しています。
ここに他の人が興味を持っているかもしれないものがあります。 https://github.com/PE-INTERNATIONAL/shiro-jersey#readme