Local Identity Providers - Employee SSO to foreign applications
|
|
- Sibyl Hoover
- 7 years ago
- Views:
Transcription
1 Local Identity Providers - Employee SSO to foreign applications IT- & Telestyrelsen, Center for Serviceorienteret Infrastruktur February 2010
2 Contents > 1 Introduction Advantages of federation 4 2 Architecture components 6 3 Basic scenario 8 4 Other considerations Establishing trust Metadata exchange Representing access right information Identity Provider discovery 12 5 Identity Provider integration User authentication Storing access right information Network deployment considerations 15 6 Service Provider integration Access control policy Integration with local access control systems Network deployment considerations 19 Appendix A: References 21
3 Document History Version Date Initials Changes TG Document created
4 1 Introduction > This guide describes how two organizations can federate using the Danish OIOSAML profile of the OASIS SAML 1 standard. The focus is on the public sector but the techniques can be applied in other sectors as well. The basic idea in federation with local identity providers is that employees in one organization (A) can seamlessly and securely access (web) applications provided by a foreign organization (B) without having to login or get a new user account there. OIOSAML solves this common problem by providing the necessary glue in the form of architecture components and protocols. This guide describes how public sector organizations can deploy federations in practice including integration with existing infrastructure such as LDAP directories. Figure 1: The Federation Concept Note that OIOSAML is also used in other federation scenarios where a central thirdparty is responsible for authenticating users (an example is the NemLog-in solutions). This is typically used for citizen egovernment applications where the user does not belong to a natural home organization that can vouch for his identity. Such federation scenarios are not in scope for this guide which focuses exclusively on Identity Providers run within local organizations. 1.1 Advantages of federation The advantages of using the federation mechanisms described in this guide are numerous: 1 Security Assertions Markup Language see [SAMLCore] for details. 4
5 User administration burdens are greatly reduced. An organization offering an application (B) does not have to administer users / employees from other organizations (A) including their access rights to the application. Instead, users are administered in their home organization which leads to a significant reduction in the administrative burdens. Security is improved. When users are administered in their home organization, the chance of their access rights being correct are greatly improved - which in turn leads to better security. For example, when an employee changes job role or leaves an organization, a local administrator is likely to get notified and ensure that access rights are properly updated. Some organizations have even deployed identity management systems which ensure that accounts are provisioned and access rights are automatically updated when the status of an employee is changed in a master data store (e.g. HR database). If users had accounts in foreign organizations, the chance of their access rights being correctly updated over time is much smaller. Integration costs are lowered. Integration with OIOSAML is based on open, interoperable standards which lowers integration cost. If public sector organizations federate with multiple partners, the same integration components can be re-used. Commercial-Off- The-Shelves (COTS) products and free open source reference implementations of OIOSAML are available [REFIMPL]. User experience is greatly improved. Users avoid getting new accounts with every application they use (e.g. receiving a new user ID and password to remember and periodically change). They further achieve single sign-on such that they do not have to login repeatedly during their work-day. As a result, both user experience and productivity is greatly improved. Portals can seamlessly collect applications. Achieving single-sign to (web) applications allows portals to be built which collect and integrate multiple applications from different organizations. If the applications are integrated to the portal via front-channel mechanisms (e.g. iframing or linking), SSO-enabled applications that were developed for standalone use may not even need to be changed in order to become part of a portal. The Danish citizen portal (borger.dk) or company portal (virk.dk) are examples of portals utilizing front-channel integration. 5
6 2 Architecture components > Before the scenarios can be described the individual roles and components in the architecture will first be presented. SAML Identity Provider This component is deployed by an organization whose users need to access applications in other organizations. The Identity Provider component is able to authenticate the local users and subsequently issue a so-called SAML assertion (see below) that identifies the user and state his access rights to the foreign application. Thus, the Identity Provider vouches for the local user identities to the foreign organization providing the application. When the Identity Provider needs to authenticate the local user, the user may login directly using his credentials or the Identity Provider may use some local single signon mechanism deployed within the organization (e.g. Kerberos). Note that the authentication to the Identity Provider is outside the scope of OIOSAML. The Identity Provider may further need to retrieve the user s access rights when creating a SAML assertion for example from a LDAP directory where the organization manages local users. This is also outside the scope of OIOSAML. More details on how to integrate SAML Identity Provider components is provided later in this guide. SAML Service Provider This component is deployed by an organization which offers web applications to users in foreign organizations. The component interacts with the Identity Provider in the user s home organization in order to authenticate the user and receive access rights which can be used to determine whether the application can be accessed. Thus, the Service Provider still defines and enforces the access control policy for its applications - the Identity Provider just assigns privileges to users. The SAML Service Provider and SAML Identity Provider trust each other and communicate according to the protocols defined in OIOSAML. Before communication can take place, the two entities need to exchange metadata files which describe communication end-points (URLs), certificates used for digital signatures and encryption, attributes supported etc. SAML Assertion A SAML assertion is an XML document created and signed by the Identity Provider upon receiving a request to authenticate the user from a Service Provider. It includes information about the user including the user s identity, time instant when he was authenticated, the strength of the authentication mechanism, and attributes about the user which may include access right information expected by the Service Provider (e.g. roles). OIOSAML defines the content of assertions for the Danish public sector including a number of standardized identity attributes. Since access right information varies greatly from deployment to deployment, such attributes are not defined in OIOSAML and must therefore be defined locally either in an agreement between a local Identity- and Service Provider or perhaps in a sector (e.g. health care sector). OIOSAML defines rules for how to define local attributes including attribute naming conventions. 6
7 Application The application is a web application or portal that requires user authentication before protected resources can be accessed. In the scenarios below the authentication process is delegated to a separate SAML Service Provider component (which in turns delegates to an Identity Provider component in the user s organization). The Service Provider logic may also be directly embedded into the application. 7
8 3 Basic scenario > Below a basic scenario is described illustrating how a user in one organization can use a local SAML 2.0 based Identity Provider to get access to applications in a foreign domain. The scenario will serve as a guiding example throughout the document and subsequent chapters will detail different aspects of the scenario especially integration of SAML components. In the figure, the user s organization use Active Directory (Kerberos) as a local authentication solution but other solutions can be used. Figure 2: Flow in basic scenario The steps are as follows: 1. The user logs in at his local network at the beginning of the work day. 2. At some point, the user (via his browser) makes a request to a web application provided by organization B. 3. The application requires authentication and authorization of the user so it redirects the user to its local SAML-based authentication server. 4. The authentication server looks up the user s Identity Provider (discovery mechanism described below) and sends a SAML authentication request to it. 5. The SAML Identity Provider authenticates the user via the local domain controller and retrieves access rights information stored about the user in the local directory which is relevant for the relying party (org. B). It further creates a session with the user and sets its identifier in the user s common domain cookie. 6. The SAML Identity Provider builds a SAML 2.0 assertion containing authentication and authorization information about the user and returns it. 7. The SAML server in organization B validates the SAML assertion, extracts the access right information, optionally converts it to an internal format required by the application and returns it. 8
9 8. The application creates a user session and serves the request based on the user s identity and the supplied access right information. The preconditions and assumptions of the above scenario are: Organization B trusts organization A to authenticate their own users and administer their access rights for applications. The two organizations have exchanged SAML metadata including which access right information (groups, roles, privileges) the relying party (organization B) requires. Organization B has split its SAML implementation from the application (step 3). In some situations the SAML implementation may be embedded directly in the application. Administrators in organization A have assigned access rights required by organization B to relevant users (e.g. using Active Directory). The Service Provider (org. B) is able to determine which Identity Provider to request authentication from (see discovery below). The SAML Identity Provider in organization A only has to use the local domain controller for user authentication on the first invocation. Subsequently, it has its own session with the user and can issue the token automatically. 9
10 4 Other considerations > This chapter describes a number of areas to consider when establishing a federation between public sector organizations. OIOSAML only provides architecture, protocols and policies, but there will be many other things to consider including legal and organizational issues, how access rights are represented and integration with existing infrastructure. 4.1 Establishing trust A fundamental pre-condition in a federation is that trust is established between Identity Providers and Service Providers. For example, a Service Provider must trust an Identity Provider to correctly authenticate users, vouch for their identity and assert their access rights, as well as operate a secure system and follow agreed procedures and policies. As a starting point, any Identity Provider that wishes to participate in the Danish public sector federation 2 will have to enter an agreement with the federation (Brugerstyringssekretariatet in Økonomistyrelsen). The federation has defined a baseline that must be met by its Identity Providers including technical requirements, security requirements, policy requirements for example regarding logging policies, time policies etc. When an Identity Provider has been accepted by the federation its metadata are published on the federation web site in a so-called white list. Thus, Service Providers can check that an Identity Provider is present in the white list and have confidence that the federation s requirements have been met Local agreements A Service Provider organization will typically have a number of terms and conditions for using their applications which go beyond federation requirements (which are application and data agnostic). Conversely, the organization using the application (Identity Provider) may also have requirements for the Service Provider e.g. regarding the quality of service of the application since the application may be critical to business processes at the Identity Provider. Therefore, a local agreement will have to be made between Identity Provider and Service Provider. The agreement may regulate many areas including roles and responsibilities, procedures, quality of service, security requirements including access control policy for the application, requirements for handling of sensitive data released by the application and requirements for the Identity Provider organization to properly manage user access to the application according the Service Provider s policies. 2 In Danish: Den fællesoffentlige føderation 10
11 4.2 Metadata exchange After organizational trust has been established and legal agreements entered, the Service Provider and Identity Provider need to exchange metadata (i.e. each import the partner s metadata file in their own system). The metadata file for an organization contains technical information about a SAML deployment including end-points (URLs) for SAML services, certificates used for signing and encryption, and supported attributes. Note that the format of metadata is standardized and further profiled in OIOSAML. Importing the partner s metadata file implies that technical trust is established i.e. the SAML servers will now accept and rely on SAML requests signed by the partner s digital signature. 4.3 Representing access right information Many applications not only require authentication of users but also need information about the user s access rights which can be group membership, roles or privileges to differentiate access. With local Identity Providers, access right information should be managed by local administrators in the user s home organization. In order for this to work, the Service Provider must a priori communicate to the Identity Provider which access right information that is needed as well as semantics and policies. For example, an application may need an attribute named role whose values can be manager, purchaser, admin or regular_employee. This policy is stated to the Identity Provider which must ensure that local administrators internally assign these roles to users that need access to the application and during run-time that issued SAML assertions include the assigned roles for this application. The Service Provider must define the required access rights in terms of a set of SAML attribute names with associated values that can be included in the SAML assertion. In order to prevent collision of attribute names, OIOSAML requires the attribute name to be a URL containing as prefix the internet domain name of the organization that defines them (e.g. the Service Provider). Example: <saml:attribute Name= urn:dk:dmp:attributes:roles NameFormat= urn:oasis:names:tc:saml:2.0:attrname-format:basic > <saml:attributevalue>miljoe_natur_naturdata_fdc,miljoe_natur_naturdata_laes </saml:attributevalue> </saml:attribute> Note that the Service Provider organization may have multiple applications each defining a different set of access right attributes. In order not to expose this complexity to all the organizations that use the application, the concept of role mapping may be employed. This means that the Service Provider externally requires Identity Providers to use only a few, consolidated roles, and that it internally maps these roles to application roles thus shielding complexity. The Service Provider s requirements for access right attributes may be communicated as part of metadata or by an out-of-band mechanism to the Identity Provider. For 11
12 example, a SAML metadata file may include an <AttributeConsumingService> element which lists (by name) the attributes required by an application. 4.4 Identity Provider discovery A central issue is how the Service Provider discovers a user s Identity Provider when he accesses an application. In order to do this, the Service Provider should take the following steps: 1. First it should try to read the common domain cookie (domain is fobs.dk in the Danish Public Sector Federation) to see if it identifies the user s current Identity Provider. It is mandatory for OIOSAML compliant Identity Providers to set the common domain cookie when the user is authenticated, so if the user has a current session with an Identity Provider, the cookie will be set. 2. If the common domain cookie does not resolve the user s Identity Provider, the Service Provider will have to ask the user to select his Identity Provider from the list of Identity Providers is has federated with (user selects his home organization). Note that the common domain cookie in OIOSAML is transient so it will be removed when the browser is restarted. 12
13 5 Identity Provider integration > This chapter describes integration that is usually required by the Identity Provider organization. It is assumed that the Identity Provider has acquired and configured a SAML component either a commercial product or an open source implementation 3. A number of considerations for integration with existing infrastructure are described below. The details of the integration will vary somewhat depending both on SAML product and existing infrastructure for user management. 5.1 User authentication The Identity Provider is responsible for authenticating local users before issuing SAML assertions to the application. This can be done in a number of different ways including: Authentication using credentials stored in the organization s LDAP directory. Authentication using a single sign-on solution deployed in the organization (e.g. Kerberos). Authentication using an employee digital certificate issued by an external Certificate Authority (e.g. the Danish OCES employee certificate). The chosen authentication mechanism must be integrated with the SAML product (i.e. the login page); most SAML products allow custom login mechanisms to be used and many even support Kerberos and LDAP directories out of the box (so integration is a matter of configuration and not programming). One important detail is that the strength of the user authentication mechanism must be reflected in the issued SAML assertion. OIOSAML specifies a mandatory attribute called AssuranceLevel which has a value in the range 1-4. A higher number means stronger assurance in the claimed identity; usually username/password authentication is mapped to level 2 and authentication with a (software based) digital signature is mapped to level 3, but other factors than the authentication method are also important including procedures for issuance of credentials. The Identity Provider must perform an analysis of the assurance level achieved by his authentication and reflect this in the issued assertion. For details on assurance level we refer to [AUTH-LEV] and [AUTH- LEV2]. Note that Service Providers may choose to grant access to sensitive applications (and data) based on the assurance level provided by the Identity Provider. In fact, Service Providers should perform a risk analysis of their applications and data in order to establish the required assurance level. This means that users from an organization that implements a low assurance level (i.e. have weak control over users) may not be able to access sensitive applications. 3 Open source reference implementations of OIOSAML in Java and.net are available from 13
14 5.2 Storing access right information As explained previously, Service Providers may define access right attributes that the Identity Provider organization must assign to users and include in the issued SAML assertions. There are several ways to store this information: Access rights can be stored in an enterprise directory which is already used to hold information on users and their access rights for internal applications. A special-purpose relational database can be used. Functionality provided by the Identity Provider product can be used. The right choice will largely depend on how the organization administers users for internal purposes. For example, an organization may have deployed user administration solutions for internal applications that should be leveraged in order not to create a new island of administration. Furthermore, the Identity Provider product must be able to retrieve this information when issuing SAML assertions. Most SAML products can retrieve user information from a wide variety of data sources and such functionality is worth considering when products are evaluated. Below a simplistic example is shown where information from a user data store is included in a SAML assertion. When the user Bob is accessing an application at organization B, the local Identity Provider at organization A performs a query in the data store and finds out that organization B expects an attribute with the name roles and that the value assigned to Bob (by a local administrator in organization A) for this attribute is manager,administrator. Therefore, the Identity Provider includes this as an attribute in the SAML assertion sent to the Service Provider. Figure 3: Including access right information from user store in SAML Assertion 14
15 One common solution is to store the access right information in an LDAP directory such as Active Directory. Here there are at least two choices: a) The information can be stored using groups from the directory. b) The information can be stored as custom attributes on the user object. When the information is stored as LDAP group membership (option a) the values will typically be the Distinguished Name (DN) of the groups. This may be problematic because the Service Provider selects the values of access right attributes and thus directly forces group objects in the Identity Provider s directory. If this option is considered, some kind of mapping of group DNs should be used to provide a level of indirection. Instead, it may be better to store the access right information as custom attributes on the user object in the directory (option b) or in a separate relational database. Generally, the Service Provider should define access right attribute names and values that can be stored in both directories and relational databases. This means that the names and values should be simple string (e.g. not XML values) without special characters. Further, attribute names should be unique to the Service Provider to avoid conflicts. Finally, the Identity Provider may want to store the attributes such that they are identified with the Service Provider who needs them. The assertion for a specific Service Provider should only contain the attributes required by that particular Service Provider. 5.3 Network deployment considerations The server hosting the Identity Provider does normally not have to be accessible from the Internet since communication with the Service Provider happens via the user s browser (using http redirect and post binding). One exception to this can be if the SAML single logout protocol is used with SOAP binding (which is optional in OIOSAML). This means that the Identity Provider component can normally be deployed in an internal network zone (for example a zone dedicated to servers which also hosts the corporate directory so the directory can be used for user authentication). If the single logout protocol via SOAP binding is needed, the Identity Provider needs to be placed in a network zone that allows both in- and outbound connections to/from the Internet. This can either be a de-militarized zone 4 (DMZ) or a special zone depending on the current network topology. When deploying an Identity Provider component it is very important to protect the private key used for signing assertions since this is the crown jewel of the system. If a hacker is able to steal the private key he could create his own security tokens and 4 Note that a DMZ does normally not allow out-bound connections to the Internet according to best practice, so any exceptions in the firewall should be restricted to a particular sever for a particular port. Many organizations probably already have network zones that allow out-bound SOAP requests. 15
16 access service provider applications on behalf of any user in the Identity Provider s organization. Therefore, if the key is stored in a file, it should be access protected using mechanisms offered by the operating system and encrypted under a password of good quality. 16
17 6 Service Provider integration > This chapter describes integration that is usually required by the Service Provider organization which offers an application to external users. It is assumed that the Service Provider has acquired and configured a SAML component either a commercial product or an open source implementation. A number of considerations for integration with existing infrastructure are described below. The details of the integration will vary somewhat depending both on SAML product and existing software. 6.1 Access control policy Before applications can be deployed for external access, the Service Provider should analyze its requirements for assurance in the user identity and define an access control policy. As described previously, the assurance level is a measure of how certain one can be that the claimed identity of the user is correct. It depends both on organizational controls and procedures as well as technical mechanisms. The Service Provider must a priori classify its applications (see [AUTH-LEV2] for details) in order to determine what assurance level is required for access. This will for example depend on which kind of data the application exposes. During runtime, the Identity Provider will inform about the assurance level for the current user via the SAML assertion. The Service Provider must configure its system to inspect this attribute and only grant access if the assurance level satisfies the requirements. Additionally, the Service Provider must analyze the applications to determine which privileges that are required. For example, an application may require the user to possess a certain role, be member of a group etc. If the Service Provider exposes multiple applications with different requirements it may be a good idea to define a set of abstract, consolidated roles (visible to the Identity Provider) and map these to the internal application roles (hidden from the Identity Provider). The access control policy must be communicated to the Identity Provider organization such that privileges can be configured in the system and assigned to users. Information on the required SAML attributes (syntax) can be part of the metadata file or be communicated using another mechanism. Additionally, some textual description is usually needed to explain how the access rights should be assigned by user administrators. 6.2 Integration with local access control systems The user s identity and access control privileges are received via the SAML assertion from the Identity Provider during run-time. The Service Provider must use this information to make an access decision: should the user be granted access to the requested application resource or not? This implies that some integration between the 17
18 SAML component and an access control component 5 is needed (unless they are not part of the same system). The nature of this integration will depend on how the Service Provider handles access control in his IT architecture; for example, access control can be handled in the following ways: a) It can be part of the SAML product (i.e. an access control suite that supports SAML). b) It can be a separate server managing access control for all the organization s applications (e.g. a reverse proxy that only allows requests to pass if they are compliant with policy). c) It can be handled by the application server (container) hosting the application (e.g. J2EE declarative security). d) It can be handled by the application itself (not recommended but very common). One common technique is to have a SAML component first validate the SAML assertion and subsequently forward important information as key/value pairs for further downstream processing by a separate access control server. This is illustrated in the figure below, where no policy enforcement is performed in the application: Figure 4: Example of access policy enforcement Another common integration pattern (type c above) is to write plug-ins to middleware in the underlying application server / container which implement authentication and access control so called Pluggable Authentication Modules (PAMs). The idea behind this is to separate authentication and authorization logic such that it later be replaced without touching the applications. 5 This component is normally called a Policy Enforcement Point (PEP). 18
19 The plug-ins are usually realized by implementing a few classes (plug-ins) with defined interfaces that allows the server middleware to query information about e.g. the user identity, group memberships and roles. Thus, the plug-in just needs to know the user and the middleware handles everything else including session management and access control decisions using pre-defined policies. This is illustrated in the figure below where a custom SAML plug-in (red box) enables federation for multiple applications. Note that a prerequisite for this integration is that applications have been designed to off-load user and access management to the application server (i.e. using so called declarative security). If the applications have hard-coded access control logic themselves this will have to be re-written. Figure 5: Custom plug-in to application server Examples of plug-ins architectures are RoleProvider and MembershipProvider in ASP.Net and JAAS modules in Java. Code samples with.net plugins created for the Umbraco CMS system using the OIOSAML.NET reference implementation can be found on Softwarebørsen Network deployment considerations The server hosting the Service Provider component does normally not have to be accessible from the Internet since communication with the Identity Provider happens via the user s browser (using http redirect and post binding). One exception to this can be if the SAML single logout protocol is used with SOAP binding (which is optional in OIOSAML). This means that the Service Provider component can normally be deployed in an internal network zone. If single logout via SOAP binding is needed, the Service Provider needs to be placed in a network zone that allows connections to and from the Internet. This can either be a de-militarized zone or a special zone depending on the current network topology
20 When deploying a Service Provider component it is important to protect the private key used for signing authentication requests and decrypting responses. If a hacker is able to steal the private key he could decrypt assertions and learn the content of sensitive attributes. Therefore, if the key is stored in a file, it should be access protected using mechanisms offered by the operating system and encrypted under a password of good quality. 20
21 Appendix A: References > [OIOSAML] [SAMLCore] [SAMLGlos] [AUTH-LEV] [AUTH-LEV2] [REFIMPL] OIO Web SSO Profile V2.0.6, IT- og Telestyrelsen. Assertion and Protocols for the OASIS Security Assertion Markup Language 2.0, OASIS Standard os.pdf Glossary for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard. Vejledning vedrørende niveauer af autenticitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-inløsning, Økonomistyrelsen, Version Referenceimplementationer af OIOSAML i Java og.net:
22
OIOSAML Rich Client to Browser Scenario Version 1.0
> OIOSAML Rich Client to Browser Scenario Version 1.0 Danish Agency for Digitization December 2011 Contents > 1 Introduction 4 1.1 Purpose 1.2 Background 4 4 2 Goals and Assumptions 5 3 Scenario Details
More informationSAML-Based SSO Solution
About SAML SSO Solution, page 1 SAML-Based SSO Features, page 2 Basic Elements of a SAML SSO Solution, page 2 SAML SSO Web Browsers, page 3 Cisco Unified Communications Applications that Support SAML SSO,
More informationOIO Web SSO Profile V2.0.5
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
More informationSAML-Based SSO Solution
About SAML SSO Solution, page 1 SAML-Based SSO Features, page 2 Basic Elements of a SAML SSO Solution, page 2 SAML SSO Web Browsers, page 3 Cisco Unified Communications Applications that Support SAML SSO,
More informationRevised edition. OIO Web SSO Profile V2.0.9 (also known as OIOSAML 2.0.9) Includes errata and minor clarifications
OIO Web SSO Profile V2.0.9 (also known as OIOSAML 2.0.9) Revised edition Includes errata and minor clarifications Danish Agency for Digitisation September 2012 Contents > 1 Introduction 8 1.1 Referenced
More informationRevised edition. OIO Web SSO Profile V2.0.8 (also known as OIOSAML 2.0.8) Includes errata and minor clarifications
OIO Web SSO Profile V2.0.8 (also known as OIOSAML 2.0.8) Revised edition Includes errata and minor clarifications Danish Agency for Digitisation December 2011 Contents > 1 Introduction 8 1.1 Referenced
More informationImplementation Guide SAP NetWeaver Identity Management Identity Provider
Implementation Guide SAP NetWeaver Identity Management Identity Provider Target Audience Technology Consultants System Administrators PUBLIC Document version: 1.10 2011-07-18 Document History CAUTION Before
More informationOIO SAML Profile for Identity Tokens
> OIO SAML Profile for Identity Tokens Version 1.0 IT- & Telestyrelsen October 2009 Content > Document History 3 Introduction 4 Related profiles 4 Profile Requirements 6 Requirements 6
More informationFlexible Identity Federation
Flexible Identity Federation Quick start guide version 1.0.1 Publication history Date Description Revision 2015.09.23 initial release 1.0.0 2015.12.11 minor updates 1.0.1 Copyright Orange Business Services
More informationDeploying RSA ClearTrust with the FirePass controller
Deployment Guide Deploying RSA ClearTrust with the FirePass Controller Deploying RSA ClearTrust with the FirePass controller Welcome to the FirePass RSA ClearTrust Deployment Guide. This guide shows you
More informationAgenda. How to configure
dlaw@esri.com Agenda Strongly Recommend: Knowledge of ArcGIS Server and Portal for ArcGIS Security in the context of ArcGIS Server/Portal for ArcGIS Access Authentication Authorization: securing web services
More informationNew Single Sign-on Options for IBM Lotus Notes & Domino. 2012 IBM Corporation
New Single Sign-on Options for IBM Lotus Notes & Domino 2012 IBM Corporation IBM s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM s sole
More informationSingle Sign-On Implementation Guide
Single Sign-On Implementation Guide Salesforce, Winter 16 @salesforcedocs Last updated: November 4, 2015 Copyright 2000 2015 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark
More informationSingle Sign-On Implementation Guide
Single Sign-On Implementation Guide Salesforce, Summer 15 @salesforcedocs Last updated: July 1, 2015 Copyright 2000 2015 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of
More informationThis chapter describes how to use the Junos Pulse Secure Access Service in a SAML single sign-on deployment. It includes the following sections:
CHAPTER 1 SAML Single Sign-On This chapter describes how to use the Junos Pulse Secure Access Service in a SAML single sign-on deployment. It includes the following sections: Junos Pulse Secure Access
More informationSAML Security Option White Paper
Fujitsu mpollux SAML Security Option White Paper Fujitsu mpollux Version 2.1 February 2009 First Edition February 2009 The programs described in this document may only be used in accordance with the conditions
More informationAmeritas Single Sign-On (SSO) and Enterprise SAML Standard. Architectural Implementation, Patterns and Usage Guidelines
Ameritas Single Sign-On (SSO) and Enterprise SAML Standard Architectural Implementation, Patterns and Usage Guidelines 1 Background and Overview... 3 Scope... 3 Glossary of Terms... 4 Architecture Components...
More informationSecuring Web Services From Encryption to a Web Service Security Infrastructure
Securing Web Services From Encryption to a Web Service Security Infrastructure Kerberos WS-Security X.509 TLS Gateway OWSM WS-Policy Peter Lorenzen WS-Addressing Agent SAML Policy Manager Technology Manager
More informationSingle Sign-On Implementation Guide
Version 27.0: Spring 13 Single Sign-On Implementation Guide Last updated: February 1, 2013 Copyright 2000 2013 salesforce.com, inc. All rights reserved. Salesforce.com is a registered trademark of salesforce.com,
More informationAn Oracle White Paper August 2010. Oracle OpenSSO Fedlet
An Oracle White Paper August 2010 Oracle OpenSSO Fedlet Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated
More informationPingFederate. Salesforce Connector. Quick Connection Guide. Version 4.1
PingFederate Salesforce Connector Version 4.1 Quick Connection Guide 2011 Ping Identity Corporation. All rights reserved. PingFederate Salesforce Quick Connection Guide Version 4.1 June, 2011 Ping Identity
More informationAn Oracle White Paper Dec 2013. Oracle Access Management Security Token Service
An Oracle White Paper Dec 2013 Oracle Access Management Security Token Service Disclaimer The following is intended to outline our general product direction. It is intended for information purposes only,
More informationSetup Guide Access Manager 3.2 SP3
Setup Guide Access Manager 3.2 SP3 August 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE
More informationIBM WebSphere Application Server
IBM WebSphere Application Server SAML 2.0 web single-sign-on 2012 IBM Corporation This presentation describes support for SAML 2.0 web browser Single Sign On profile included in IBM WebSphere Application
More informationWeb Applications Access Control Single Sign On
Web Applications Access Control Single Sign On Anitha Chepuru, Assocaite Professor IT Dept, G.Narayanamma Institute of Technology and Science (for women), Shaikpet, Hyderabad - 500008, Andhra Pradesh,
More informationCA Performance Center
CA Performance Center Single Sign-On User Guide 2.4 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation ) is
More informationSAML SSO Configuration
SAML SSO Configuration Overview of Single Sign-, page 1 Benefits of Single Sign-, page 2 Overview of Setting Up SAML 2.0 Single Sign-, page 3 SAML 2.0 Single Sign- Differences Between Cloud-Based Meeting
More informationCA Single Sign-On Migration Guide
CA Single Sign-On Migration Guide Web access management (WAM) systems have been a part of enterprises for decades. It is critical to control access and audit applications while reducing the friction for
More informationE-Authentication Federation Adopted Schemes
E-Authentication Federation Adopted Schemes Version 1.0.0 Final May 4, 2007 Document History Status Release Date Comment Audience Template 0.0.0 1/18/06 Outline PMO Draft 0.0.1 1/19/07 Initial draft Internal
More informationSafewhere*Identify 3.4. Release Notes
Safewhere*Identify 3.4 Release Notes Safewhere*identify is a new kind of user identification and administration service providing for externalized and seamless authentication and authorization across organizations.
More informationHybrid for SharePoint Server 2013. Search Reference Architecture
Hybrid for SharePoint Server 2013 Search Reference Architecture 2014 Microsoft Corporation. All rights reserved. This document is provided as-is. Information and views expressed in this document, including
More informationSAML Federated Identity at OASIS
International Telecommunication Union SAML Federated Identity at OASIS Hal Lockhart BEA Systems Geneva, 5 December 2006 SAML and the OASIS SSTC o SAML: Security Assertion Markup Language A framework for
More informationSingle Sign-On Implementation Guide
Salesforce.com: Salesforce Winter '09 Single Sign-On Implementation Guide Copyright 2000-2008 salesforce.com, inc. All rights reserved. Salesforce.com and the no software logo are registered trademarks,
More informationINTEGRATION GUIDE. IDENTIKEY Federation Server for Juniper SSL-VPN
INTEGRATION GUIDE IDENTIKEY Federation Server for Juniper SSL-VPN Disclaimer Disclaimer of Warranties and Limitation of Liabilities All information contained in this document is provided 'as is'; VASCO
More informationSAP Certified Technology Professional - Security with SAP NetWeaver 7.0. Title : Version : Demo. The safer, easier way to help you pass any IT exams.
Exam : P_ADM_SEC_70 Title : SAP Certified Technology Professional - Security with SAP NetWeaver 7.0 Version : Demo 1 / 5 1.Which of the following statements regarding SSO and SAP Logon Tickets are true?
More informationSecuring access to Citrix applications using Citrix Secure Gateway and SafeWord. PremierAccess. App Note. December 2001
Securing access to Citrix applications using Citrix Secure Gateway and SafeWord PremierAccess App Note December 2001 DISCLAIMER: This White Paper contains Secure Computing Corporation product performance
More informationSTUDY ON IMPROVING WEB SECURITY USING SAML TOKEN
STUDY ON IMPROVING WEB SECURITY USING SAML TOKEN 1 Venkadesh.M M.tech, Dr.A.Chandra Sekar M.E., Ph.d MISTE 2 1 ResearchScholar, Bharath University, Chennai 73, India. venkadeshkumaresan@yahoo.co.in 2 Professor-CSC
More informationDocuSign Single Sign On Implementation Guide Published: March 17, 2016
DocuSign Single Sign On Implementation Guide Published: March 17, 2016 Copyright Copyright 2003-2016 DocuSign, Inc. All rights reserved. For information about DocuSign trademarks, copyrights and patents
More informationWhite Paper Cybercom & Axiomatics Joint Identity & Access Management (R)evolution
White Paper Cybercom & Axiomatics Joint Identity & Access Management (R)evolution Federation and Attribute Based Access Control Page 2 Realization of the IAM (R)evolution Executive Summary Many organizations
More informationFederated Identity Management Solutions
Federated Identity Management Solutions Jyri Kallela Helsinki University of Technology jkallela@cc.hut.fi Abstract Federated identity management allows users to access multiple services based on a single
More informationCopyright Pivotal Software Inc, 2013-2015 1 of 10
Table of Contents Table of Contents Getting Started with Pivotal Single Sign-On Adding Users to a Single Sign-On Service Plan Administering Pivotal Single Sign-On Choosing an Application Type 1 2 5 7 10
More informationIntroduction to SAML
Introduction to THE LEADER IN API AND CLOUD GATEWAY TECHNOLOGY Introduction to Introduction In today s world of rapidly expanding and growing software development; organizations, enterprises and governments
More informationHow To Use Saml 2.0 Single Sign On With Qualysguard
QualysGuard SAML 2.0 Single Sign-On Technical Brief Introduction Qualys provides its customer the option to use SAML 2.0 Single Sign On (SSO) authentication with their QualysGuard subscription. When implemented,
More informationOnly LDAP-synchronized users can access SAML SSO-enabled web applications. Local end users and applications users cannot access them.
This chapter provides information about the Security Assertion Markup Language (SAML) Single Sign-On feature, which allows administrative users to access certain Cisco Unified Communications Manager and
More informationOpenLDAP Oracle Enterprise Gateway Integration Guide
An Oracle White Paper June 2011 OpenLDAP Oracle Enterprise Gateway Integration Guide 1 / 29 Disclaimer The following is intended to outline our general product direction. It is intended for information
More informationGENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK
Antti Pyykkö, Mikko Malinen, Oskari Miettinen GENERAL OVERVIEW OF VARIOUS SSO SYSTEMS: ACTIVE DIRECTORY, GOOGLE & FACEBOOK TJTSE54 Assignment 29.4.2008 Jyväskylä University Department of Computer Science
More informationSAP NetWeaver Single Sign-On. Product Management SAP NetWeaver Identity Management & Security June 2011
NetWeaver Single Sign-On Product Management NetWeaver Identity Management & Security June 2011 Agenda NetWeaver Single Sign-On: Solution overview Key benefits of single sign-on Solution positioning Identity
More informationTenrox. Single Sign-On (SSO) Setup Guide. January, 2012. 2012 Tenrox. All rights reserved.
Tenrox Single Sign-On (SSO) Setup Guide January, 2012 2012 Tenrox. All rights reserved. About this Guide This guide provides a high-level technical overview of the Tenrox Single Sign-On (SSO) architecture,
More informationCA Single Sign-On r12.x (CA SiteMinder) Implementation Proven Professional Exam
CA Single Sign-On r12.x (CA SiteMinder) Implementation Proven Professional Exam (CAT-140) Version 1.4 - PROPRIETARY AND CONFIDENTIAL INFORMATION - These educational materials (hereinafter referred to as
More informationIdentity Implementation Guide
Identity Implementation Guide Version 37.0, Summer 16 @salesforcedocs Last updated: May 26, 2016 Copyright 2000 2016 salesforce.com, inc. All rights reserved. Salesforce is a registered trademark of salesforce.com,
More informationComputer Systems Security 2013/2014. Single Sign-On. Bruno Maia ei09095@fe.up.pt. Pedro Borges ei09063@fe.up.pt
Computer Systems Security 2013/2014 Single Sign-On Bruno Maia ei09095@fe.up.pt Pedro Borges ei09063@fe.up.pt December 13, 2013 Contents 1 Introduction 2 2 Explanation of SSO systems 2 2.1 OpenID.................................
More informationFederations 101. An Introduction to Federated Identity Management. Peter Gietz, Martin Haase
Authentication and Authorisation for Research and Collaboration Federations 101 An Introduction to Federated Identity Management Peter Gietz, Martin Haase AARC NA2 Task 2 - Outreach and Dissemination DAASI
More informationOpenSSO: Cross Domain Single Sign On
OpenSSO: Cross Domain Single Sign On Version 0.1 History of versions Version Date Author(s) Changes 0.1 11/30/2006 Dennis Seah Contents Initial Draft. 1 Introduction 1 2 Single Domain Single Sign-On 2
More informationUSING FEDERATED AUTHENTICATION WITH M-FILES
M-FILES CORPORATION USING FEDERATED AUTHENTICATION WITH M-FILES VERSION 1.0 Abstract This article provides an overview of federated identity management and an introduction on using federated authentication
More informationCA Nimsoft Service Desk
CA Nimsoft Service Desk Single Sign-On Configuration Guide 6.2.6 This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to as the Documentation
More informationKantara egov and SAML2int comparison
Kantara egov and SAML2int comparison 17.8.2010/mikael.linden@csc.fi This document compares the egovernment Implementation profile of SAML 2.0, created by the egovernment WG of Kantara Initiative, and the
More informationINCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES
INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES Participation in the InCommon Federation ( Federation ) enables a federation participating organization ("Participant") to use Shibboleth identity
More informationBuilding Secure Applications. James Tedrick
Building Secure Applications James Tedrick What We re Covering Today: Accessing ArcGIS Resources ArcGIS Web App Topics covered: Using Token endpoints Using OAuth/SAML User login App login Portal ArcGIS
More informationArchitectural Overview
Architectural Overview Version 7 Part Number 817-2167-10 March 2003 A Sun ONE Application Server 7 deployment consists of a number of application server instances, an administrative server and, optionally,
More informationSAML and OAUTH comparison
SAML and OAUTH comparison DevConf 2014, Brno JBoss by Red Hat Peter Škopek, pskopek@redhat.com, twitter: @pskopek Feb 7, 2014 Abstract SAML and OAuth are one of the most used protocols/standards for single
More informationINCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES
INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES Participation in the InCommon Federation ( Federation ) enables a federation participating organization ("Participant") to use Shibboleth identity
More informationHansoft LDAP Integration
Hansoft LDAP Integration The Hansoft LDAP Integration synchronizes Hansoft resources to user accounts in an LDAP directory server, such as Windows Active Directory. It matches accounts on login names and
More informationPortWise Access Management Suite
Create secure virtual access for your employees, partners and customers from any location and any device. With todays global and homogenous economy, the accuracy and responsiveness of an organization s
More informationExtranet Access Management Web Access Control for New Business Services
Extranet Access Management Web Access Control for New Business Services An Evidian White Paper Increase your revenue and the ROI for your Web portals Summary Increase Revenue Secure Web Access Control
More informationWeb Access Management and Single Sign-On
Web Access Management and Single Sign-On Ronnie Dale Huggins In the old days of computing, a user would sit down at his or her workstation, login to the desktop, login to their email system, perhaps pull
More informationOpenID Connect 1.0 for Enterprise
OpenID Connect 1.0 for Enterprise By Paul Madsen Executive Overview In order to meet the challenges presented by the use of mobile apps and cloud services in the enterprise, a new generation of identity
More informationAGILEXRM REFERENCE ARCHITECTURE
AGILEXRM REFERENCE ARCHITECTURE 2012 AgilePoint, Inc. Table of Contents 1. Introduction 4 1.1 Disclaimer of warranty 4 1.2 AgileXRM components 5 1.3 Access from PES to AgileXRM Process Engine Database
More informationRedpaper Axel Buecker Craig Forster Sridhar Muppidi Borna Safabakhsh
Redpaper Axel Buecker Craig Forster Sridhar Muppidi Borna Safabakhsh IBM Tivoli Security Policy Manager Introduction In a growing number of enterprises, policies are the key mechanism by which the capabilities
More informationSAML Single-Sign-On (SSO)
C O L A B O R A T I V E I N N O V A T I O N M A N A G E M E N T Complete Feature Guide SAML Single-Sign-On (SSO) 1. Features This feature allows administrators to setup Single Sign-on (SSO) integration
More informationArchitecture Guidelines Application Security
Executive Summary These guidelines describe best practice for application security for 2 or 3 tier web-based applications. It covers the use of common security mechanisms including Authentication, Authorisation
More informationPerceptive Experience Single Sign-On Solutions
Perceptive Experience Single Sign-On Solutions Technical Guide Version: 2.x Written by: Product Knowledge, R&D Date: January 2016 2016 Lexmark International Technology, S.A. All rights reserved. Lexmark
More informationTest Plan for Liberty Alliance SAML Test Event Test Criteria SAML 2.0
1 2 3 4 5 6 7 8 9 10 11 Test Plan for Liberty Alliance SAML Test Event Test Criteria SAML 2.0 Version 3.2.2 Editor: Kyle Meadors, Drummond Group Inc. Abstract: This document describes the test steps to
More informationAuthentication Integration
Authentication Integration VoiceThread provides multiple authentication frameworks allowing your organization to choose the optimal method to implement. This document details the various available authentication
More informationBiometric Single Sign-on using SAML Architecture & Design Strategies
Biometric Single Sign-on using SAML Architecture & Design Strategies Ramesh Nagappan Java Technology Architect Sun Microsystems Ramesh.Nagappan@sun.com 1 Setting Expectations What you can take away! Understand
More informationIMPLEMENTING SINGLE SIGN- ON USING SAML 2.0 ON JUNIPER NETWORKS MAG SERIES JUNOS PULSE GATEWAYS
APPLICATION NOTE IMPLEMENTING SINGLE SIGN- ON USING SAML 2.0 ON JUNIPER NETWORKS MAG SERIES JUNOS PULSE GATEWAYS SAML 2.0 combines encryption and digital signature verification across resources for a more
More informationBlackBerry Enterprise Server for Microsoft Exchange Version: 5.0 Service Pack: 2. Administration Guide
BlackBerry Enterprise Server for Microsoft Exchange Version: 5.0 Service Pack: 2 Administration Guide Published: 2010-06-16 SWDT487521-1041691-0616023638-001 Contents 1 Overview: BlackBerry Enterprise
More informationAuthentication and Single Sign On
Contents 1. Introduction 2. Fronter Authentication 2.1 Passwords in Fronter 2.2 Secure Sockets Layer 2.3 Fronter remote authentication 3. External authentication through remote LDAP 3.1 Regular LDAP authentication
More informationGoogle Apps Deployment Guide
CENTRIFY DEPLOYMENT GUIDE Google Apps Deployment Guide Abstract Centrify provides mobile device management and single sign-on services that you can trust and count on as a critical component of your corporate
More informationSAM Context-Based Authentication Using Juniper SA Integration Guide
SAM Context-Based Authentication Using Juniper SA Integration Guide Revision A Copyright 2012 SafeNet, Inc. All rights reserved. All attempts have been made to make the information in this document complete
More informationWorkday Mobile Security FAQ
Workday Mobile Security FAQ Workday Mobile Security FAQ Contents The Workday Approach 2 Authentication 3 Session 3 Mobile Device Management (MDM) 3 Workday Applications 4 Web 4 Transport Security 5 Privacy
More informationOSOR.eu eid/pki/esignature Community Workshop in Brussels, 13. November 2008 IT Architect Søren Peter Nielsen - spn@itst.dk
The OIOSAML Toolkits Accelerating a common egov infrastructure using open source reference implementations OSOR.eu eid/pki/esignature Community Workshop in Brussels, 13. November 2008 IT Infrastructure
More informationTIBCO Spotfire Platform IT Brief
Platform IT Brief This IT brief outlines features of the system: Communication security, load balancing and failover, authentication options, and recommended practices for licenses and access. It primarily
More informationArchitecture and Data Flow Overview. BlackBerry Enterprise Service 10 721-08877-123 Version: 10.2. Quick Reference
Architecture and Data Flow Overview BlackBerry Enterprise Service 10 721-08877-123 Version: Quick Reference Published: 2013-11-28 SWD-20131128130321045 Contents Key components of BlackBerry Enterprise
More informationWebNow Single Sign-On Solutions
WebNow Single Sign-On Solutions Technical Guide ImageNow Version: 6.7. x Written by: Product Documentation, R&D Date: June 2015 2012 Perceptive Software. All rights reserved CaptureNow, ImageNow, Interact,
More informationHow To Use Netiq Access Manager 4.0.1.1 (Netiq) On A Pc Or Mac Or Macbook Or Macode (For Pc Or Ipad) On Your Computer Or Ipa (For Mac) On An Ip
Setup Guide Access Manager 4.0 SP1 May 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF A LICENSE
More informationIntegrating CRM On Demand with the E-Business Suite to Supercharge your Sales Team
Integrating CRM On Demand with the E-Business Suite to Supercharge your Sales Team Presented by: Tom Connolly, Jason Lieberman Company: BizTech Session ID: #10351 Overview Introductions Background Web
More informationConfiguring EPM System 11.1.2.1 for SAML2-based Federation Services SSO
Configuring EPM System 11.1.2.1 for SAML2-based Federation Services SSO Scope... 2 Prerequisites Tasks... 2 Procedure... 2 Step 1: Configure EPM s WebLogic domain for SP Federation Services... 2 Step 2:
More informationIntegration Guide. SafeNet Authentication Service. SAS Using RADIUS Protocol with Microsoft DirectAccess
SafeNet Authentication Service Integration Guide SAS Using RADIUS Protocol with Microsoft DirectAccess Technical Manual Template Release 1.0, PN: 000-000000-000, Rev. A, March 2013, Copyright 2013 SafeNet,
More informationEnhancing Web Application Security
Enhancing Web Application Security Using Another Authentication Factor Karen Lu and Asad Ali Gemalto, Inc. Technology & Innovations Austin, TX, USA Overview Introduction Current Statet Smart Cards Two-Factor
More informationIdentity Server Guide Access Manager 4.0
Identity Server Guide Access Manager 4.0 June 2014 www.netiq.com/documentation Legal Notice THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE TERMS OF
More informationADFS Integration Guidelines
ADFS Integration Guidelines Version 1.6 updated March 13 th 2014 Table of contents About This Guide 3 Requirements 3 Part 1 Configure Marcombox in the ADFS Environment 4 Part 2 Add Relying Party in ADFS
More informationOpenHRE Security Architecture. (DRAFT v0.5)
OpenHRE Security Architecture (DRAFT v0.5) Table of Contents Introduction -----------------------------------------------------------------------------------------------------------------------2 Assumptions----------------------------------------------------------------------------------------------------------------------2
More informationIntegrating VMware Horizon Workspace and VMware Horizon View TECHNICAL WHITE PAPER
Integrating VMware Horizon Workspace and VMware Horizon View TECHNICAL WHITE PAPER Table of Contents Introduction.... 3 Requirements.... 3 Horizon Workspace Components.... 3 SAML 2.0 Standard.... 3 Authentication
More informationINCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES
INCOMMON FEDERATION: PARTICIPANT OPERATIONAL PRACTICES Participation in the InCommon Federation ( Federation ) enables a federation participating organization ("Participant") to use Shibboleth identity
More informationIntegrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies
Guideline Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies Product(s): IBM Cognos 8 BI Area of Interest: Security Integrating IBM Cognos 8 BI with 3rd Party Auhtentication Proxies 2 Copyright
More informationConfiguring Single Sign-On from the VMware Identity Manager Service to Office 365
Configuring Single Sign-On from the VMware Identity Manager Service to Office 365 VMware Identity Manager JULY 2015 V1 Table of Contents Overview... 2 Passive and Active Authentication Profiles... 2 Adding
More informationWebLogic Server 7.0 Single Sign-On: An Overview
WebLogic Server 7.0 Single Sign-On: An Overview Today, a growing number of applications are being made available over the Web. These applications are typically comprised of different components, each of
More informationUsing Foundstone CookieDigger to Analyze Web Session Management
Using Foundstone CookieDigger to Analyze Web Session Management Foundstone Professional Services May 2005 Web Session Management Managing web sessions has become a critical component of secure coding techniques.
More informationBiometric Single Sign-on using SAML
Biometric Single Sign-on using SAML Architecture & Design Strategies Ramesh Nagappan CISSP Ramesh.Nagappan@sun.com 1 Setting Expectations What you can take away! Understand the importance of Single Sign-On
More informationDocument Management Software Provider Designs for Identity and Access Flexibility
Microsoft Windows Server System Partner Solution Case Study Document Management Software Provider Designs for Identity and Access Flexibility Overview Country or Region: Canada Industry: Professional Services
More information