100 likes | 327 Views
IETF86 OpenID Workshop. Using OpenID Connect on Non-Web environment. PEOFIAMP Project. 2013-03-10. Nat Sakimura Nomura Research Institute Boku Kihara Kazuki Shimizu Lepidum. About PEOFIAMP Project. Funded by Ministry of Internal Affairs and Communication in FY 2012
E N D
IETF86 OpenID Workshop Using OpenID Connect on Non-Web environment PEOFIAMP Project 2013-03-10 Nat Sakimura Nomura Research Institute BokuKihara Kazuki Shimizu Lepidum
About PEOFIAMP Project • Funded by Ministry of Internal Affairs and Communication in FY 2012 • Joint project of National Institute of Informatics, U.of Tokyo, U.of Kyoto, NRI • Project Partners • ※1 TERENA: Trans-European Research and Education Networking Associationhttp://www.terena.org/ • ※2 REFEDS: https://refeds.org/ • ※3 GEANT: Multi-gigabit european research and education network and associated serviceshttp://www.geant.net/ • ※4 eduGAIN: http://www.edugain.org/
Solution in two phases • Account Linking and Credential issuance phase • The account at the IdP and the account at the application service provider is linked in this phase; • Per application credential, a.k.a. access token is issued to each application; • The credential is stored in the user agents; • Per application credential usage phase • The credential provided by the user agent is handed over to the PAM module which verifies it:
Phase 1: Credential Issuance • The end-user accesses the web page of the service provider in order to obtain the information including the "password (access token)" to use a client application. • The end-user logs in to the web page using his/her local credentials, typically a username and a password for the application, e.g., IMAP. • The end-user selects an OpenID provider and the service provider sends an authentication and authorization request to the OpenID Provider with auth scope values. • The OpenID Provider asks the end-user whether he/she wants to authorize the request. It is RECOMMENDED for the OpenID Provider to provide the end-user with methods to distinguish access tokens in order to revoke the intended access token if necessary such as a user specified nickname for the client, e.g., "my iphone", "my pc thunderbird", etc.
The service provider receives an authorization response and obtains a Bearer type access token. • The service provider receives the sub claim from the OpenID Provider by using the access token or by decoding ID token if exists, and links the OpenID Provider, the sub claim, and the local account that the service provider manages. • The service provider shows the access token to the end-user and instruct to copy the access token to the password box on the client application.
Phase 2: Credential Usage • The client application sends the "paasword" (access token) to the service provider. • The service provider sends UserInfo request to the OpenID Provider with the access token. [[Note: it could be to the token introspection endpoint, or a structured token such as ID Token]] • The OpenID Provider returns UserInfo response described in the section 2.2. • The service provider checks whether the there is the claim name that the service provider requires. • The service provider checks whether the sub claim is the same as the value that was obtained in the access token issue flow and makes an authorization decision based on it.
Example: IMAP C: a001 LOGIN alice eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJpc3M... [Here, the service provider validates the token.] S: a001 OK LOGIN completed
Project Status • I-D created • http://tools.ietf.org/html/draft-sakimura-oidc-extension-nonweb • Implementation • Linux PAM implementation completed. • IMAP, SMTP, SSH working. • Probably, anything that uses PAM would work • (For IdP, the project used and modified a Ruby implementation by Nov Matake.)