A lot of mobile applications (app) provide services that require the user to authenticate using their social networking identities and authorize the app to access their personal data. The result is that the user can consume the service while the app can access personal data belonging to the user. The problem is that the user needs to log in and authorize each app even if the social identity used by the user is the same across multiple apps. The Authorizing Agent (AZA) will solve the problem of repeated authorizations if the identity used by the user is the same for multiple apps. The initial ideas are well captured in the forum started by engineers from Ping and the draft spec. The suggestion is that an agent will reside on the mobile phone. The agent will take the responsibility of authorizing apps on the user's behalf thus reducing the burden on the user for repeated authorizations. This idea might trigger some good initiatives across the mobile app development apart from Single Sign On which is obvious.
Consolidation of Enterprise Mobile Apps
For years enterprises have been building mobile apps with custom authentication and authorization mechanisms. AZA can be deployed as a service that is reusable on the mobile platform. App developers can build the features of the app and leverage this service for authentication and authorization. The service and app will be separate entities. App developers can concentrate on app development while the service is maintained by the security developers. Each team should make sure that respin of either entity, App or Service, will not break the overall integration.
This could help consolidation of apps in an enterprise and the same standards for mobile app development can be used across different teams.
User Managed Access (UMA) and Scope sharing
As disscussed earlier, users authorize apps to access their personal data. The app can access depending on the consent given by the user during app authorization. The user basically gives permission to access some of his/her personal data. UMA proposes that an external entity should host all the user's permissions and any app requesting user's personal data should interact with the host instead of the user.
AZA could act as the host and host the user consent or permissions. Currently, each app requests permissions to access user's personal data. Even though the identity used by the user may be the same for these apps, each app requires specific data. The problem of authorizing each app and maintaing permissions given to each app can be solved if AZA acts like UMA host and avoids user intervention. User intervention is needed only if the permission requested by the app is not hosted by AZA. Once the permission is authorized by the user, AZA could update a list that contains permission information for subsequent app requests.
If implemented, AZA might open an authentication and authorization services on the mobile phone. AZA services will run closer to the user and might allow the user to revoke permissions and authorization to certain clients. By peppering it with risk based authentication an intelligent system can be developed. I hope the specs and groups will discuss such details further.
Of course, all this comes at a risk. Control to the AZA, revoking permissions and authorizations when something goes wrong such as a lost device, leaked credentials need to be thought about. But, all in all I think it is a great experiment worth trying. My best wishes to Ping and Oracle who have ventured into this experiment.
Consolidation of Enterprise Mobile Apps
For years enterprises have been building mobile apps with custom authentication and authorization mechanisms. AZA can be deployed as a service that is reusable on the mobile platform. App developers can build the features of the app and leverage this service for authentication and authorization. The service and app will be separate entities. App developers can concentrate on app development while the service is maintained by the security developers. Each team should make sure that respin of either entity, App or Service, will not break the overall integration.
This could help consolidation of apps in an enterprise and the same standards for mobile app development can be used across different teams.
User Managed Access (UMA) and Scope sharing
As disscussed earlier, users authorize apps to access their personal data. The app can access depending on the consent given by the user during app authorization. The user basically gives permission to access some of his/her personal data. UMA proposes that an external entity should host all the user's permissions and any app requesting user's personal data should interact with the host instead of the user.
AZA could act as the host and host the user consent or permissions. Currently, each app requests permissions to access user's personal data. Even though the identity used by the user may be the same for these apps, each app requires specific data. The problem of authorizing each app and maintaing permissions given to each app can be solved if AZA acts like UMA host and avoids user intervention. User intervention is needed only if the permission requested by the app is not hosted by AZA. Once the permission is authorized by the user, AZA could update a list that contains permission information for subsequent app requests.
If implemented, AZA might open an authentication and authorization services on the mobile phone. AZA services will run closer to the user and might allow the user to revoke permissions and authorization to certain clients. By peppering it with risk based authentication an intelligent system can be developed. I hope the specs and groups will discuss such details further.
Of course, all this comes at a risk. Control to the AZA, revoking permissions and authorizations when something goes wrong such as a lost device, leaked credentials need to be thought about. But, all in all I think it is a great experiment worth trying. My best wishes to Ping and Oracle who have ventured into this experiment.
No comments:
Post a Comment