6th European Conference - Academic Conferences

Maria Semmelrock-Picej et al.
A clear interface needs to be developed with non virtual customers - they like tidy relationships
and clear contracts. Thus either one member of the virtual cooperation must act on behalf of the
others (using them as subcontractors) or create a joint company to act as their legal entity and
administration service.
The highly dynamic business forces Infineon to set up strategic alliances (project partnerships)
frequently, in order to be competitive in cost and time. The chip design process and the production
environment (silicon foundries) serve as good examples for necessary alliances. While partnerships in
the course of the chip design aim at reducing the time to market, alliances during the production focus
on covering customer demands which increase the available production capacities. Especially the
design process for very complex chips sometimes requires setting up an alliance with one or more
competitors to reduce the overall development costs of the chip. For the automotive industry (one of
our three business areas), highly-logic special-function chips are designed. The business strategy of
Infineon also includes cooperation in terms of an alliance with a customer to develop “next
generation” chips which represent a quantum leap in technology and/or function (Schelmer 2008).
Today a complex process for the setup of collaborations exist (see figure 5)
The process starts with an internal employee requesting an identity entry in the IDMS for the external
persons belonging to other organisations of the business alliance. The following phases include the
provisioning of resources and carrying out the revocation of access on the respective resources once
the alliance ends. This process is applied for each (strategic) alliance wherein external staff is
involved.
However, this approach requires an internal employee at Infineon to trigger a lot of things prior to an
external alliance partner being able to start performing his tasks. A lot of single resources have to be
provisioned for the external partners (there is currently no role-model and a suitable tooling available)
accompanied by a lot of approval workflows which slows down the whole setup process. Furthermore,
knowledge about external employees, e.g. which resources they need to access at Infineon, is
necessary in advance (reduction in flexibility). Moreover, today the whole identity information of
external persons is also kept in the IDMS whereby the data volume is blowing up.
To overcome these deficiencies, the approach of Federated Identity Management (also called identity
federations) whose core idea is to allow individuals to use the same accounts and passwords they
have in their company to get access to a network of another company was established.
At first a user’s identity data is maintained at an identitiy provider in its IDMS. In the context of SPIKE
the partner company of INF takes over the role of an identity provider, while INF acts as service
provider during this collaboration. Subsequently, the user tries to access a service (an application, a
data source, and so on) of the service provider. Thereby, the user is verified at the identity provider
(the collaboration partner) by the service provider (INF). If the identity provider successfully
authenticates the data – or spoken in SPIKE terminology fulfils the tasks which were negotiated in the
collaboration contract -, the user will get access to the requested service.
Business partners trust each other for the user authentication mechanisms they employ in their
company and also guarantee that only authenticated users will have access to services (resources,
applications) of the alliance partner. This is a precondition for companies to use applications in a
common way without being forced to use the same directory services, authentication mechanisms
and duplicate digital identities to the other system.
Federated Identity Management also reduces the administration overhead in an alliance because it is
not required that the collaboration partner has to know the involved employees who need access to
the resources of the alliance partner in advance. The identity provider has also a large flexibility to
manage (exchange, increase, decrease) the staff during the existence of the alliance according to the
needs of the service provider. The service provider only has to care for the access to applications
needed by both companies (e.g. design application in the chip design area or administration
applications in the IT area, and so on).
In the next chapters the requirements of the component SPIKE/IF (identity federation module) of a life
cycle model for collaborations will be described in order to overcome the mentioned deficiencies.
245