44
Copyright © 2009 Open Geospatial Consortium, Inc. Please enter the following extra attributes to be sent with your
certificate request A challenge password []:
enter
An optional company name []:
enter
Request is in newreq.pem, private key is in newkey.pem
11.4.6 Extract Public and Private Keys
The public RSA key was then extracted from the certificate using the “openssl rsa” which writes it to the “pubkey.pem” file as shown below. The content of this file was used later
to register the web application.
openssl rsa -in newkey.pem -pubout -out pubkey.pem enter
Enter pass phrase for newkey.pem:
certpassword enter
writing RSA key
The private key was extracted from the certificate into the PKCS8 format required by the Java Security API using the “openssl pkcs8” command as shown below The private
key was written to the “privkey.pem” file which was used by the web application to sign future requests.
openssl pkcs8 -topk8 -nocrypt -in newkey.pem -out privkey.pem enter
Enter pass phrase for newkey.pem:
certpassword enter
11.4.7 Create a Web Application Entry on the OpenID Server
The public key generated in the previous steps was then used to create a new Web Application Entry for the application with the OpenID server. For this testbed the
Geobliki OpenID server displays a user interface form that was used to enter required information including the content of the “pubkey.pem” file created earlier to complete the
application entries as shown in Figure 14.
Cop
Figure 14, Create a new Web Application Entry on the OpenID Server
The new generated OpenID https:op.geobliki.comappJavaTest1 shown in Figure 15 will be used as the OAuth consumer key for future requests by this application.
Figure 15, OpenID Application Consumer Key
yright © 2009 Open Geospatial Consortium, Inc.
45
46
Cop
11.4.8 Cross-Domain Authority Delegation
OAuth was originally designed independently of OpenID to allow users to provide access to their resources to other services without having to relinquish their usernames and
passwords to those services.
In this testbed the OpenID server and the Service Provider were not in the same security domain. To access resources in another domain, permission must be obtained by the
consumer to access resources published by a provider in a different security domain on the user’s behalf. The user must be registered to a trusted community of OpenID
providers and have a notification capability, such as XMPP or SMS, shown as Notification URI below to support authorizations in real-time. The OpenID server
interface used in this testbed to enter the user’s identity profile is shown in Figure 16 below.
Figure 16, OpenID Server Interface to enter User’s Identity Profile
yright © 2009 Open Geospatial Consortium, Inc.
Cop
Given the OpenID profile defined above, the transaction can be achieved using OAuth and OpenID as shown in Figure 17 and described in the paragraphs that follow.
Figure 17, Delegation of Authority using OAuth and OpenID
The Application Consumer uses the user’s OpenID as the OAuth token. The Service Provider SPS then uses the OpenID to retrieve the user profile that has been established
across the secure domains. Notification is provided to the user’s OpenID provider that a request is being made to access resources on his behalf. The user then accepts or rejects
the request. The grant will remain permanent until explicitly revoked by the user. The following steps describe the sequence of interactions depicted in Figure 17 shown above.
11.4.9 Application Consumer OAuth request
