Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Access Management
11g Release 2 (11.1.2)

Part Number E27239-03
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

39 Configuring Internet Identity Services

Mobile and Social provides a graphical user interface for configuring Internet Identity Services. This chapter describes how to use the Oracle Access Management Console to configure Mobile Services and contains the following topics.

Note:

Internet Identity Services can also be configured from the command line using WLST. For more information about the Mobile and Social WLST commands, see the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

39.1 Navigating the Internet Identity Services Graphical User Interface

The Internet Identity Services graphical user interface (GUI) can be displayed after an administrator has successfully authenticated and received access to the Oracle Access Management Console. The Console is divided into the following parts:

Follow this procedure to access the Internet Identity Services configuration page.

  1. Log in to the Oracle Access Management Console.

  2. Click the System Configuration tab at the top of the Console.

  3. Click Mobile and Social on the left side of the page.

  4. Click Internet Identity Services.

    The Welcome to Mobile and Social - Internet Identity Services page loads in the home area.

39.2 Understanding Internet Identity Services Configuration

The Welcome to Mobile and Social - Internet Identity Services configuration page displays in the home area. It is divided into separate panels that can be viewed or hidden during administration. The following sections contain more information on the Internet Identity Services panels.

39.2.1 Understanding Internet Identity Providers

The Internet Identity Provider panel is used to edit the (preconfigured) configuration details for Identity Providers such as Google, Facebook, Twitter, and the like. Once established, you should not need to modify these settings very often.

You can also define configuration details for Internet Identity Providers that you add yourself by implementing the oracle.security.idaas.rp.spi.IdentityProvider Java interface. For information about adding additional Internet Identity Providers, see "Extending the Capabilities of the Mobile and Social Server" in the Developer's Guide for Oracle Access Management.

More information on Internet Identity Providers is in Section 39.3, "Defining Internet Identity Providers."

39.2.2 Understanding Service Provider Interfaces

The Service Provider Interface refers to the set of rules that govern the authentication flow for the specified Application Profile. Mobile and Social provides the following Service Provider Interfaces.

  • DefaultServiceProviderInterface - provides support for web applications that run on Java-compliant application servers.

  • OAMServiceProviderInterface - provides support for web applications that run on the Access Manager service.

More information on Service Provider Interfaces is in Section 39.4, "Defining Service Provider Interfaces."

Note:

A Java developer can write custom implementations of one or more of the Identity Provider interface contracts. Use the Service Provider Interfaces section only if you need to add a custom Service Provider created by a developer.

39.2.3 Understanding Application Profiles

An Application Profile defines an application that uses Internet Identity Provider services on the Mobile and Social server. Use this panel to configure mobile applications, web applications that run on Java-compliant application servers, and web applications that are integrated with Access Manager to use Internet Identity Services.

  • If a web application is not integrated with Access Manager, integrate the Internet Identity Services login page with the web application. See the "Developing Applications Using the Internet Identity Services Client SDK" chapter in the Developer's Guide for Oracle Access Management for details.

  • If the web application is integrated with Access Manager, edit the preconfigured Application Profile named OAMApplication. When Access Manager and Mobile and Social are installed together during Oracle Access Management installation, both products are registered as trusted partners and the preconfigured Application Profile is included. As a result, you do not need to write code to integrate web applications that are integrated with Access Manager and Internet Identity Services. The OAMApplication Application Profile that is included with Mobile and Social is preconfigured to work with Access Manager and requires only minor configuration changes to get working in your environment.

More information on Application Profiles is in Section 39.5, "Defining Application Profiles."

39.3 Defining Internet Identity Providers

The Internet Identity Provider collects configuration details for Identity Providers such as Google, Facebook, Twitter, and the like. Once created, you should not need to modify Internet Identity Provider settings very often. The following sections provide information regarding creating, modifying and deleting Internet Identity Providers.

39.3.1 Creating an Internet Identity Provider

  1. Open the Internet Identity Services Home Page in the Oracle Access Management Console as described in Section 39.1, "Navigating the Internet Identity Services Graphical User Interface."

  2. Click Create in the Internet Identity Provider panel in the home area.

    The Create New Internet Identity Provider configuration page displays.

  3. Enter values for the Internet Identity Provider properties.

    • Name - Type a unique name for this Authentication Service Provider.

    • Description - (Optional) Type a short description that will help you or another Administrator identify this service in the future.

    • Internet Identity Provider Protocol - Select the Identity Provider from the drop down menu.

      • Google (OpenID)

      • Yahoo (OpenID)

      • Facebook (OAuth)

      • Twitter (OAuth)

      • LinkedIn (OAuth)

      Select Custom to configure a custom Identity Provider. Your choice here will change the displayed Protocol Attributes and User Attributes Returned panels to reflect properties more specific to the authentication protocol being used by the Internet Identity Provider - either OpenID or OAuth.

    • Implementation Class - Based on the Internet Identity Provider Protocol selection, the appropriate provider-specific implementation of the oracle.security.idaas.rp.spi.IdentityProvider Java interface will be populated in this field. (If Custom, enter the corresponding implementation class that should interact with the Identity Provider.) The Mobile and Social server will use this information to communicate with this Internet Identity Provider.

  4. Enter values for the Protocol Attributes properties based on the protocol being used by the Internet Identity Provider previously selected: OpenID (Table 39-1) or OAuth (Table 39-2) . (If Custom, add all values required by the custom Provider and related to the authentication protocol used.)

    • Provide values required by the Identity Provider implementing the OpenID protocol as specified in Table 39-1.

      Table 39-1 OpenID Protocol Attributes

      Name Values Notes

      Yadis Endpoint

      Must be an absolute HTTP or HTTPS URL

      Type the published URL that accepts OpenID authentication protocol messages for this Identity Provider. Mobile and Social uses this URL to make user authentication requests.

      Hashing Algorithm

      • SHA256 is a 256-bit key length algorithm

      • SHA1 is a 160-bit key length algorithm

      • None

      Choose a signature algorithm. Mobile and Social uses this value internally to configure the Session Type and Association Type properties for communicating with the Identity Provider.

      Authentication Policy

      Choose Yes to request that an authentication policy be applied by the OpenID Provider when authenticating a user. Otherwise, choose No.

      Usage of PAPE (Provider Authentication Policy Extension) allows web developers to request other modifications to the flow, such as asking that the Identity Provider re-prompt the User for their password.

      Authentication Policy Maximum Age

      Provide a value greater than or equal to zero seconds. Specify 0 to force a password re-prompt.

      Type the maximum length of time in seconds that a User who has not actively authenticated can use a login session before being required to authenticate using the requested authentication policy. Use this parameter to ensure that the login session of the user at the Identity Provider is recent.

      Preferred Authentication Policies

       

      Type zero or more URIs separated by a space that represent authentication policies that the Identity Provider must satisfy when authenticating the user. For example:

      http://schemas.openid.net/pape/policies/2007/06/phishing-resistant

      http://schemas.openid.net/pape/policies/2007/06/multi-factor


    • Provide values required by the Identity Provider implementing the OAuth protocol as specified in Table 39-2.

      Table 39-2 OAuth Protocol Attributes

      Name Value Notes

      Authorization URL

      The Identity Provider's published OAuth authorization URL. If an Identity Provider changes a published OAuth URL, update this value to match.

      Mobile and Social directs the User to this URL after the Identity Provider returns the request token (see Request Token URL). The Identity Provider verifies the User's identity, and the User grants the Identity Provider permission to release the User's protected information to the Mobile and Social server.

      Access Token URL

      Type the Identity Provider's published access token URL.

      Mobile and Social uses this URL to request an access token from the Identity Provider after the User authorizes the request token (using the Authorization URL).

      Request Token URL

      Type the Identity Provider's published Request Token URL. (Not applicable to Facebook.)

      Mobile and Social uses this URL to obtain a request token from the Identity Provider. After the Identity Provider grants the request token, the Mobile and Social server directs the User to the Identity Provider's Authorization URL. (The term temporary credentials supplants the terms request token and request secret in RFC 5849, The OAuth 1.0 Protocol.)

      Profile URL

      Type the Identity Provider's published Profile URL.

      Mobile and Social uses this URL to request User attributes based on a OAuth access token.

      Consumer Key

      Type the value that the Mobile and Social server should use to identify itself to the Identity Provider.

      See Section 39.3.3, "Generating the Consumer Key and Consumer Secret for OAuth Providers" for information about requesting a Consumer Key from the Identity Provider.

      Consumer Secret

      Type the secret that the Mobile and Social server should use to establish ownership of the Consumer Key.

      See Section 39.3.3, "Generating the Consumer Key and Consumer Secret for OAuth Providers" for information about requesting a Consumer Secret from the Identity Provider.

      Server Time Sync

      If the Mobile and Social server and a remote Identity Provider are not time synchronized, type the number of minutes of skew to add to the current server time when sending requests to the remote Provider. This field accepts both positive and negative integers.

      Typically LinkedIn requires synchronized server time values. Not applicable for Facebook or Twitter.

      In the Attribute Name column type the local application attribute name that should be assigned to the attribute name returned by the OpenID Identity Provider. In the Attribute Schema Name column, type the URL where the Mobile and Social server can request user data from the Identity Provider.

      If you add attributes in the Attribute Name column that the Identity Provider does not support, those attributes will not be available in Mobile and Social.


  5. Add values to the User Attributes Returned panel based on the Internet Identity Provider Protocol previously selected: OpenID, OAuth or Custom.

    • OpenID: In the Attribute Name column type the local application attribute name that should be assigned to the attribute name returned by the Identity Provider. In the Attribute Schema Name column, type the URL where the Mobile and Social server can request user data from the Identity Provider. If you add attributes in the Attribute Name column that the Identity Provider does not support, those attributes will not be available in Mobile and Social. Table 39-3, "User Attributes Returned By Google" and Table 39-4, "User Attributes Returned By Yahoo" lists the user attributes supported by Google and Yahoo.

      Table 39-3 User Attributes Returned By Google

      Attribute Description

      country

      Requests the user's home country. Must be set to: http://axschema.org/contact/country/home

      email

      Requests the user's Gmail address. Must be set to:

      http://axschema.org/contact/email

      firstname

      Requests the user's first name. Must be set to:

      http://axschema.org/namePerson/first

      language

      Requests the user's preferred language. Must be set to:

      http://axschema.org/pref/language

      lastname

      Requests the user's last name. Must be set to:

      http://axschema.org/namePerson/last


      Table 39-4 User Attributes Returned By Yahoo

      Attribute Description

      gender

      Requests the user's gender. Must be set to:

      http://axschema.org/person/gender

      email

      Requests the user's e-mail address. Must be set to:

      http://axschema.org/contact/email

      fullname

      Requests the user's full name. Must be set to:

      http://axschema.org/namePerson

      language

      Requests the user's preferred language. Must be set to:

      http://axschema.org/pref/language

      nickname

      Requests the user's preferred name. Must be set to:

      http://axschema.org/namePerson/friendly

      Timezone

      Requests the user's preferred time zone. Must be set to:

      http://axschema.org/pref/timezone


    • OAuth: Specify the User Profile attributes that the OAuth Identity Provider (Twitter, Facebook, and LinkedIn) should return. In the Attribute Name column type the local application attribute name that corresponds to the attribute name returned by the Identity Provider. In the Attribute Schema Name column, type the Identity Provider attribute name. For OAuth Providers, Attribute Name values and Attribute Schema Name values are usually the same.

      Note:

      LinkedIn does not return an e-mail address or an unencrypted login ID when it returns User Identity attributes to Mobile and Social. Please note this limitation when using Identity attributes from LinkedIn to pre-populate the registration form for Users.

    • Custom: In the Attribute Name column type the local application attribute name that should be assigned to the attribute name returned by the Custom Identity Provider. In the Attribute Schema Name column, type the URL where the Mobile and Social server can request user data from the Identity Provider.

  6. Click Create to create the Internet Identity Provider configuration object.

39.3.2 Editing or Deleting an Internet Identity Provider

To edit or delete an Internet Identity Provider, select the Provider in the panel and click Edit or Delete on the panel's tool bar. See Section 39.3.1, "Creating an Internet Identity Provider" for attribute descriptions.

39.3.3 Generating the Consumer Key and Consumer Secret for OAuth Providers

The following sections describe how to generate the Consumer Key and Consumer Secret for the Internet Identity Providers that support the OAuth protocol.

Note:

The steps in this section are accurate as of the date that this documentation was published. The steps required to create a Consumer Key and Consumer Secret using the Facebook, Twitter, and LinkedIn web sites are subject to change at any time.

39.3.3.1 Generating a Consumer Key and Consumer Secret for Facebook

This section describes how to generate a Consumer Key and Consumer Secret for Facebook.

  1. Open the following URL in a web browser:

    https://developers.facebook.com/apps

  2. Click Create New App.

  3. Complete the Create New App form.

    Facebook creates the application and assigns it a unique App ID and App Secret.

  4. Complete the information in the Basic Info section.

    In the Select how your application integrates with Facebook section, select Website with Facebook Login.

  5. In the Site URL field, provide the URL where the Mobile and Social Server can be reached. For example:

    http://OAM-Hosted-Machine: Port/

  6. Click Save Changes.

  7. Open for editing the "Internet Identity Providers" > "Facebook" configuration page as described in section Section 39.4.1.

  8. Paste the App ID in the Consumer Key field and paste the App Secret in the Consumer Secret field.

    Click Apply to save your changes.

39.3.3.2 Generating a Consumer Key and Consumer Secret for Twitter

This section describes how to generate a Consumer Key and Consumer Secret for Twitter.

  1. Open the following URL in a web browser:

    https://dev.twitter.com/apps/new

  2. Complete the Create an application form.

    In the Callback URL field provide the URL where the Mobile and Social Server can be reached. For example:

    http://OAM-Hosted-Machine: Port/oic_rp/return

    Twitter creates the application and assigns it a unique Consumer key and Consumer secret.

  3. (Optional) Configure your Twitter application as needed and save your changes.

  4. Open for editing the "Internet Identity Providers" > "Twitter" configuration page as described in section Section 39.4.1.

  5. Paste the Consumer Key in the Consumer Key field and paste the Consumer Secret in the Consumer Secret field.

    Click Apply to save your changes.

39.3.3.3 Generating a Consumer Key and Consumer Secret for LinkedIn

This section describes how to generate a Consumer Key and Consumer Secret for LinkedIn.

  1. Open the following URL in a web browser:

    https://www.linkedin.com/secure/developer?newapp=

  2. Complete the Add New Application form.

    In the OAuth User Agreement section, add the URL in the OAuth Redirect URL field where the Mobile and Social Server can be reached. For example:

    http://OAM-Hosted-Machine: Managed Server Port/

  3. Click Add Application.

    LinkedIn creates the application and assigns it a unique API Key and Secret Key.

  4. Open for editing the "Internet Identity Providers" > "LinkedIn" configuration page as described in section Section 39.4.1.

  5. Paste the API Key in the Consumer Key field and paste the Secret Key in the Consumer Secret field.

    Click Apply to save your changes.

39.3.4 Troubleshooting Internet Identity Providers

This section documents known configuration issues that affect the Facebook Internet Identity Provider.

39.3.4.1 Configuring WebLogic Server for Facebook Compatibility

Follow these steps to configure WebLogic Server to support Facebook.

  1. Open the WebLogic Console.

    http://host:port/console

  2. Choose Domain > Environment > Servers > Managed Server.

  3. Click the SSL tab, then click Advanced.

  4. Click Lock and Edit configuration.

  5. Change the Host Name Verifier to None.

  6. Restart the Managed Server.

If Host Name Verifier is not set to None, the following error may display when trying to access a protected resource if Facebook is the Identity Provider:

Exception in processRequest method: oracle.security.idaas.rp.RPException:
oracle.security.idaas.rp.RPException: Request failed:

39.3.4.2 Configuring WebLogic Server 10.3.5 and Older for Facebook Compatibility

Facebook's SSL certificate contains *.facebook.com as a wildcard host identifier. WebLogic Server versions 10.3.5 and older have a problem verifying host names that contain wildcards that can lead to communication failures between Facebook and installations of Oracle Access Management Mobile and Social deployed on WebLogic Server. The following workarounds are available.

  • If using WebLogic Server versions 10.3.5 or older, follow these steps:

    1. In the administration console, choose servers > oam_server_where_Mobile_and_Social_is_deployed > SSL > Advanced.

    2. Change Hostname Verifier to NONE.

  • This WebLogic Server bug has been fixed in version 10.3.6 as follows: A new custom hostname verifier SSLWLSWildcardHostnameVerifier was implemented, derived from the default hostname verifier, so that it supports everything the default hostname verifier does, including SANs. You must configure your WebLogic server to use this custom hostname verifier if support for wildcard certificates is required during the SSL handshake. One option is to use the following WebLogic property:

    -Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildca rdHostnameVerifier
    

39.4 Defining Service Provider Interfaces

The Service Provider Interface refers to the set of rules that govern the authentication flow for the specified Application Profile. Mobile and Social provides the following Service Provider Interfaces.

If necessary, a Java developer can write custom implementations of one or more of the Identity Provider interface contracts. This section includes the following topics:

39.4.1 Creating a Service Provider Interface

  1. Open the Internet Identity Services Home Page in the Oracle Access Management Console as described in Section 39.1, "Navigating the Internet Identity Services Graphical User Interface."

  2. Click Create in the Service Provider Interface panel in the home area.

    The Create New Service Provider Interface configuration page displays.

  3. Enter values for the Service Provider Interface properties.

    • Name - Type a unique name for this Authentication Service Provider.

    • Description - (Optional) Type a short description that will help you or another Administrator identify this service in the future.

  4. Enter values for the Interface Information properties as specified in Table 39-5.

    Table 39-5 Service Provider Interface Information Properties

    Name Notes

    IDP Selector

    Choose the IDP Selector implementation class for the custom Provider.

    Post IDP Selector

    Choose the Post IDP Selector implementation class for the custom Provider.

    IDP Interaction Provider

    Choose the IDP Interaction Provider implementation class for the custom Provider.

    Registration Status Check

    Choose the Registration Status Check implementation class for the custom Provider.

    Session Creation Provider

    Choose the Session Creation Provider implementation class for the custom Provider.


  5. Click Create to create the Service Provider Interface configuration object.

39.4.2 Editing or Deleting an Service Provider Interface

To edit or delete a Service Provider Interface, select the Provider in the panel and click Edit or Delete on the panel's tool bar. See Section 39.4.1, "Creating a Service Provider Interface" for attribute descriptions.

39.4.3 Adding a Custom Service Provider Interface Implementation

To add a custom interface implementation, create a new Internet Identity Provider and choose a mix of custom and/or default implementation classes as needed to meet your business objectives. See "Developing Applications Using the Internet Identity Services Client SDK" in the Developer's Guide For Oracle Access Management for information.

39.5 Defining Application Profiles

An Application Profile defines an application that uses Internet Identity Provider services on the Mobile and Social server. Use this panel to configure mobile applications, web applications that run on Java-compliant application servers, and web applications that are integrated with Access Manager to use Internet Identity Services.

Typically, when a WebGate is configured in Access Manager, an Application Domain is created involving resources and policies. In Mobile and Social, OAMApplication is the Application Profile that corresponds to the Access Manager Application Domain. So, if you define 10 WebGates in Access Manager, and each represents an application that needs to use Mobile and Social for user authentication, use OAMApplication as a template to create 10 corresponding Application Profiles with names that match the 10 Application Domains.

Note:

When you install a WebGate to protect an application in Access Manager, the WebGate setup automatically creates an Application Domain that has LDAP as the authentication mechanism. To use Mobile and Social authentication, change the Authentication Scheme to OICScheme.

This section provides help for the Create Application Profile wizard and the Edit Application Profiles page.

The following sections contain more information.

39.5.1 Creating an Application Profile

  1. Open the Internet Identity Services Home Page in the Oracle Access Management Console as described in Section 39.1, "Navigating the Internet Identity Services Graphical User Interface."

  2. Click Create in the Application Profiles panel in the home area.

    The Create New Application Profile configuration page displays.

  3. Enter values for the general Application Profile properties.

    • Name - Displays the context name of the web application or mobile application. This name should match the name registered with the agent protecting the resource. If the application is integrated with Access Manager, the Application Domain name as defined in Access Manager is displayed. This should be the same value as that of the Name defined in the Mobile Services Application Profile, if applicable.

    • Description - (Optional) Type a short description that will help you or another Administrator identify this service in the future.

    • Shared Secret - For mobile or web applications, provide the security secret that the application and the Mobile and Social server share to facilitate secure communication. This is needed to use the Mobile and Social user registration functionality. It can be any string.

    • Return URL - This value is not used if the application is a mobile application but it is a mandatory attribute. So for mobile applications, use the Mobile Application Return URL. For web applications, provide the URL that Mobile and Social should use to send back authentication responses. If the application is integrated with Access Manager, provide the following URL which Mobile and Social uses to send back authentication responses:

      http://oam-host:port/oam/server/dap/cred_submit

    • Mobile Application Return URL - For mobile applications, provide the URL that Mobile and Social should use to send back authentication responses. This value should match the mobile application's return URL.

  4. Enter values for the following Application Profile configuration properties.

    • Login Type - Choose Local Authentication and Internet Identity Provider Authentication if the User login page should let users choose between authenticating locally and authenticating using an Identity Provider. Choose Internet Identity Provider Authentication only if the User login page should not give the users the option of authenticating locally. The Mobile and Social login page supports Internet Identity Provider Authentication only; no local login supported.

    • Enable Browser Popup - Choose Yes if the login page should open in a pop-up window. This value should be false if this is a mobile application.

    • User Registration - Choose Enabled to allow users to register with the application after authenticating against an Internet Identity Provider. The login page for the application will show a User Registration form and prompt the User to register. The User can complete the form and register, or click the Skip Registration button. Choose Disabled if the login page should not show a User Registration form and should not prompt the User to register.

    • Registration URL - Type the URL that the system should forward the User to so that the User can register for a local account. Typically the User is directed to a form with fields that correspond to the registration service attributes defined in the Application Profile. An encrypted token with attribute objects in a map are also passed to the client application as a parameter. These attributes are used to pre-populate the registration page with the User's profile data.

    • UserID Attribute - Type the attribute name that is used to uniquely identify the User. This attribute name should also appear in the Application User Attribute section of the Application Profile Configuration page.

    • User Profile Service Endpoint - Choose the User Profile Service endpoint that the application should use. The User Profile Service directs the application to the LDAP Directory service where the User will be created upon registration. User Profile Service endpoints are configured in Mobile Services.

    • Authentication Service Endpoint - The Authentication Service endpoint determines how the user should be authenticated when local login is requested. If a mobile application, choose InternetIdentityAuthentication or any custom authentication of the type InternetIdentityAuthentication.

      • Choose /oamauthentication to forward the authentication request to Access Manager. The authentication scheme associated with the Mobile and Social Authentication Policy inside the IAMSuite Application domain determines how the user will be authenticated.

      • Choose /internetidentityauthentication to use the Identity Store specified in the corresponding endpoint.

    • Application Profile Properties - Click Add to add Application Profile attributes to the table. The following are supported.

      • app.passwd.field - Encrypts the password on the registration page. Add password as the value. To mask the password with asterisks (*) on the registration page, add the app.passwd.field property and add password as the value.

      • oic.app.idp.oauth.token - Instructs Mobile and Social to include the OAuth Access Token as part of the final redirect to the application. Add true as the value. Only applies if the User selected an OAuth provider (Facebook, Twitter, LinkedIn).

      • oic.app.user.token - Creates a JWT User Token when a User authenticates with an Identity Provider and gets redirected back to the application. Add true as the value. This token contains the Identity Provider related URI and the User identifier value on record with the Identity Provider. Use this token to access other protected Mobile and Social REST services, for example the User Profile REST Service.

  5. Click Add to add the Application User Attributes that the Internet Identity Provider should return to the application after authentication.

    Configure more details for these attributes in the following Registration Service Details with Application User Attribute Mapping step.

  6. Add rows to the Registration Service Details with Application User Attribute Mapping table to map local (User) registration attributes to the application attributes provided by the Internet Identity Provider.

    Add any additional Application User Attributes in the previous step first. The following definitions apply to the Registration Service Details with Application User Attribute Mapping table properties.

    • Registration Service Attribute - Choose from the menu the registration service attribute to configure.

    • User Attribute Display Name - For the attribute in the Registration Service Attribute column, type the name that should appear on the User registration form. This is the attribute name that the user sees.

    • Read-only - Select to prevent the user from updating the attribute value. The attribute value will display grayed-out on the form and the user will be blocked from making updates.

      Note:

      Do not select the Read-only option for First Name and Last Name if Yahoo is the Internet Identity Provider. Yahoo does not return values for these attributes. Selecting the Read-only option will cause user registration to fail and an exception error to display.

    • Mandatory - Select to make the attribute a required item on the user registration form.

    • Application User Attribute - Choose the attribute that corresponds to the attribute in the Registration Service Attribute column.

  7. Click Next to configure the Service Provider Interface.

    The Sevice Provider Interface page displays.

  8. Choose the DefaultServiceProviderInterface from the drop down menu.

    For information about the Service Provider Interface, see Section 39.4, "Defining Service Provider Interfaces."

  9. Click Next to configure the Internet Identity Provider.

    The Internet Identity Provider page displays. Use this section to select one or more Internet Identity Providers, and to map local application user attributes to Internet Identity Provider attributes. For example, to use an e-mail address as the unique local user identifier when Google is the Internet Identity Provider:

    1. Select Google in the Internet Identity Provider column.

      A two-column table opens.

    2. Create the mapping as follows:

      1. Choose uid in the first row of the Application User Attribute column.

      2. Choose email in the Internet Identity Provider User Attributes column.

  10. Click Finish to create the Application Profile.

39.5.2 Editing or Deleting an Application Profile

To edit or delete an Application Profile, select the Profile in the panel and click Edit or Delete on the panel's tool bar. See Section 39.5.1, "Creating an Application Profile" for attribute descriptions.

39.6 Integrating Internet Identity Services With Mobile Applications

You can configure Mobile Services to allow applications on mobile devices to authenticate using Internet Identity Services. Any application that needs to use Internet Identity Services must have a corresponding Application Profile in Internet Identity Services. If you want a mobile application to use Internet Identity Services, the application needs to have a profile under Internet Identity Services and under Mobile Services.

  1. Under Internet Identity Services, open the Create Application Profile wizard.

  2. Populate the Application Profile attributes with values applicable to the mobile application being protected and click Next.

    See Section 39.5.1, "Creating an Application Profile" for attribute definitions.

  3. Select the Service Provider Interface and click Next.

    See Section 39.4, "Defining Service Provider Interfaces."

  4. Select the Internet Identity Provider and click Next.

    See Section 39.2, "Understanding Internet Identity Services Configuration."

  5. View the Application Profile summary and click Finish to create the Application Profile.

  6. Under Mobile Services, open the Create Service Domain wizard.

    If modifying an existing Service Domain, open it for editing. See Section 38.4, "Defining Service Profiles" for information.

  7. Complete the form as follows.

    • For Type, select Mobile Application.

    • For Authentication Scheme, select Internet Identity Authentication.

    See Section 38.7, "Defining Service Domains" for information.

  8. In the Application Profile Selection section, add the Mobile Services Application Profile that represents the mobile application being protected and choose if it will participate in mobile SSO as an agent, a client or not at all.

    Select the appropriate Application Profile by browsing existing Profiles or entering a name. The Application Profile must already be created. (To create Mobile Services Application Profiles, see Section 38.6, "Defining Application Profiles"; for Internet Identity Services Application Profiles, see Section 39.5, "Defining Application Profiles.")

  9. Click Next to select (or create) a Service Profile.

    See Section 38.4, "Defining Service Profiles."

  10. Click Next to select the Service Protection.

    For example, use InternetIdentityAuthentication as the authentication service to protect the User Profile Services.

  11. Click Next to view the Create Service Domain summary.

  12. Click Finish to create the Service Domain.