Pierre Cros improvements
This commit is contained in:
parent
282d8f4109
commit
d276594f3e
|
@ -9,8 +9,7 @@ Lasso Projects Basics
|
|||
|
||||
Lasso functions are defined in several header files typically located in
|
||||
``/usr/include/lasso/`` or ``/usr/local/include/lasso/``. It is possible to
|
||||
include individual files but in most case it is enough to include the main
|
||||
``lasso.h``.
|
||||
include individual files even if the main lasso.h is sufficient most often.
|
||||
|
||||
The first thing to do is then to call ``lasso_init()``. Similarly the last
|
||||
thing will be to call ``lasso_shutdown()``. The smallest and useless Lasso
|
||||
|
@ -41,6 +40,9 @@ compilation and linking.
|
|||
-lpthread -lz -lm -lglib-2.0
|
||||
|
||||
|
||||
Creating an executable from the previous sample *will then be* a simple
|
||||
matter of calling gcc with the right flags
|
||||
|
||||
Creating an executable from the previous sample would then a simple matter of
|
||||
calling ``gcc`` with the right flags. But there is currently in bug in
|
||||
XMLSec, the library used by Lasso to provide XML Signature and XML Encryption
|
||||
|
@ -82,14 +84,14 @@ A ``LassoServer`` object may be created as follows:
|
|||
- ``idp-metadata.xml`` is the Liberty metadata file for the identity provider
|
||||
- ``sp-private-key.pem`` is the service provider private key; used to sign
|
||||
documents
|
||||
- ``sp-crt.pem`` is the service provider certificate; sent inside signed
|
||||
- ``sp-crt.pem`` is the service provider certificate; sent within signed
|
||||
documents
|
||||
- ``idp-public-key.pem`` is the identity provider public key; used to verify
|
||||
signature in documents sent by the identity provider
|
||||
- ``ca-crt.pem`` is the certificate of the certification authority used by the
|
||||
identity provider.
|
||||
|
||||
It is of course possible to have several calls so ``lasso_server_add_provider``
|
||||
It is of course possible to have several calls to ``lasso_server_add_provider``
|
||||
if there are more than one identity provider.
|
||||
|
||||
LassoProfile
|
||||
|
@ -149,10 +151,10 @@ serialized into XML files. Example with a ``LassoServer``::
|
|||
g_free(dump);
|
||||
|
||||
.. note:: ``lasso_server_dump`` (and other Lasso dump functions) allocates
|
||||
memory through GLib. ``g_free`` is then the function to use instead
|
||||
memory through GLib. ``g_free`` is the function to use instead
|
||||
of ``free`` to release memory.
|
||||
|
||||
It is then really easy to get back properly constructed objects::
|
||||
It is then really easy to have properly constructed objects returned::
|
||||
|
||||
LassoServer *server;
|
||||
gchar *dump;
|
||||
|
|
|
@ -15,7 +15,26 @@ detailed and implemented in the next chapters.
|
|||
Single Sign-On and Federation
|
||||
=============================
|
||||
|
||||
A few paragraphs; what does single sign-on and federation really mean...
|
||||
The Single Sign On process allows a user to log in once to an identity provider
|
||||
(IdP), and to be then transparently loged in to the required service providers
|
||||
(SP) belonging to the IP "circle of trust". Subordinating different identities
|
||||
of the same user within a circle of trust to a unique IP is called "Identity
|
||||
Federation". The liberty Alliance specifications allows, thanks to this
|
||||
federation, strong and unique authentication coupled with control by the user
|
||||
of his personnal informations. The explicit user agreement is necessary before
|
||||
proceeding to Identity Federation.
|
||||
|
||||
The different SPs can't communicate directly together about users informations.
|
||||
They're only able to exchange informations about a user with the IP. This
|
||||
assure :
|
||||
|
||||
- private life respect;
|
||||
- increased security (an unveiled identity for one of the SPs won't
|
||||
endanger the others).
|
||||
|
||||
To insure the integrity and the non-revocability of the exchange, a trusted
|
||||
third part releases a security token which identify only the session and not
|
||||
the user.
|
||||
|
||||
|
||||
Artifact Profile
|
||||
|
|
|
@ -2,23 +2,44 @@
|
|||
Preface
|
||||
=======
|
||||
|
||||
In a digitalized world where both businesses and consumers want security in
|
||||
their transactions and other blah blah.
|
||||
In a digitalised world where both businesses and consumers want security in
|
||||
their transactions the notion of identity has become more and more crucial.
|
||||
Today one's identity on the network is fragmented across various identity
|
||||
providers, employers, business services and other communities. This
|
||||
fragmentation leads to partial and often unsatisfying customers-to-business
|
||||
relationships.
|
||||
|
||||
A Federated Network Identity allows new business opportunites and new economies
|
||||
of scale. In a world of federated commerce a user's identity, preferences,
|
||||
buying habits and history, are managed by the user himself and securely
|
||||
exchanged with the organisations of the user's choosing.
|
||||
|
||||
|
||||
The Liberty Alliance Project
|
||||
============================
|
||||
|
||||
Initiated by Sun Microsystems in 2001 with the aim to develop an alternative to
|
||||
Microsoft Passport system the Liberty Alliance project is now a worldwide
|
||||
consortium with more than 150 companies, goverments and non-profits.
|
||||
The Liberty Alliance Project was formed in September 2001 to develop
|
||||
open standards for federated network identity management and
|
||||
identity-based services. Its goals are to ensure interoperability,
|
||||
support privacy, and promote adoption of its specifications, guidelines
|
||||
and best practices. The Alliance is made up of more than 150 members,
|
||||
representing a worldwide cross-section of organizations ranging from
|
||||
educational institutions and government organizations, to service
|
||||
providers and financial institutions, to technology vendors and wireless
|
||||
providers.
|
||||
|
||||
|
||||
The Lasso Project
|
||||
=================
|
||||
|
||||
In July 2003... the CVQ project... Cross-site authentication... Further
|
||||
developments...
|
||||
In July 2003 Entr'ouvert started to develop the "Carte de Vie Quotidienne"
|
||||
project for the commune of Vandoeuvre-les-Nancy. This project quickly drove us
|
||||
to take interest in cross-site authentication problems. We identified Liberty
|
||||
Alliance specifications as the only ones potentially able to satisfy our need
|
||||
for a strong authentication, coupled with private life respect. Lasso is a
|
||||
library written in C which means it can be easily integrated within any kind of
|
||||
web service whenever a strong authentication is required. Lasso has been the
|
||||
first implementation of Liberty Alliance released under the GNU GPL license.
|
||||
|
||||
|
||||
Acknowledgments
|
||||
|
|
|
@ -177,7 +177,7 @@ login URL; the service provider must then respond with an HTTP 302 Redirect
|
|||
response, pointing the user browser to the identity provider single sign on
|
||||
service.
|
||||
|
||||
.. note:: the login URL is not normative; any name will go.
|
||||
.. note:: the login URL is not normative; any name will do.
|
||||
|
||||
|
||||
``server`` is a ``LassoServer`` as seen earlier and ``idpProviderId`` is a
|
||||
|
@ -252,10 +252,9 @@ object.
|
|||
lasso_login_accept_sso(login);
|
||||
|
||||
After ``lasso_login_accept_sso`` the session and the identity are updated (or
|
||||
created) and should then be saved. If the identity was not known to the
|
||||
service provider an account will most probably need to be created on the
|
||||
service provider; this is a good opportunity to ask the user for more
|
||||
information.
|
||||
created) and should then be saved. If the identity has not regnogized by the
|
||||
service provider an account will probably have to be created on the service
|
||||
provider; this is a good opportunity to ask the user for more information.
|
||||
|
||||
You can get respective dumps like this::
|
||||
|
||||
|
@ -345,7 +344,7 @@ Database Considerations
|
|||
=======================
|
||||
|
||||
Lasso has been designed to let the service provider keep on using existing
|
||||
databases. Typically there is already a table describing users; just add a
|
||||
databases. Typically there is already a table describing users; just add an
|
||||
identity dump column to the existing table:
|
||||
|
||||
======= ======================================== ==============
|
||||
|
|
Loading…
Reference in New Issue