= Onde está seu pasaporte?
This is Pasaporte, a small identity server with a colored bar on top. It's in the style
of Crowd (but smaller). Will act as a mediator between OpenID and arbitary services where
users are distinguished by their nickname (login), their password and a domain name.
== The idea
Pasaporte brings OpenID to the traditional simplicity of
is_a_villain = check_password(login, password, domain)
The only thing you WILL need to change is the AUTH constant. It should contain the proc
that, when called, will return true or false. Yes, it's that simple. All the negotiation
smorgasbord, profile editing, encryptodecryption and other electrabombastic niceties are
going to be taken care of.
Here is an example of a simple auth procedure:
# Stick your super auth HERE. Should be a proc accepting login, pass and domain
Pasaporte::AUTH = lambda do | login, pass, domain |
allowd = => "secret"
return (allowd[login] && (allowd[login] == pass))
end
Obviously you can let your auth procedure look up in ACLs and things like that if you
really need it to.
If the password becomes stale or should the authentication backend say that it no
longer has the user in question the authorization tokens are immediately revoked, and any
authorization requests will be denied.
== Using SSL
It is recommended that you run pasaporte in full SSL mode. However,
some OpenID consumers disallow OpenID providers with self-signed (i.e. free)
SSL certificates. Pasaporte mitigates this by offering the "partial SSL" mode. When turned on,
only the signon page (where the password is entered) and subsequent pages with which the user
interacts will be protected with SSL encryption, while the public OpenID endpoint will NOT be
SSL-enabled. Same is true for the server-server step of OpenID handshake.
This will allow even stricter providers to use Pasaporte servers, but without passing the user login
over the wire in clear text.
When partial SSL is turned on, the profile page (OpenID identity) will forcibly be made
unencrypted (will redirect to non-secure port).
Partial SSL is disabled by default - to enable set PARTIAL_SSL to true.
== Current issues
As of now, we are not aware of sites that cannot consume OpenID from Pasaporte.
There is currently no provision for verifying that the URL you are logging in from is the
one Pasaporte manages.
== Configuration
The adventurous among us can override the defaults (Pasaporte constants) by placing a
hash-formatted YAML file called "config.yml" in the pasaporte dir. And don't ask me what
a "hash-formatted YAML file" is, because if you do you are not adventurous.
Here the rundown of the config parameters:
MAX_FAILED_LOGIN_ATTEMPTS - after how many login attempts the user will be trottled
THROTTLE_FOR - Trottle length in seconds
ALLOW_DELEGATION - if set to true, the user will be able to redirect his OpenID
SESSION_LIFETIME - in seconds - how long does a session remain valid
PARTIAL_SSL - see above
HTTP_PORT - if partial SSL is used, the port on which the standard version runs
SSL_PORT - if partial SSL is used, the port on which the secure version runs
== Profiles
Pasaporte allows the user to have a simple passport page, where some info can be placed
for people who follow the OpenID profile URL. Sharing the information is entirelly optional.
== The all-id
The login that you use is ultimately the nickname that comes in the URL. For that reason
no other login name can be entered in the form. However the user still can verify that
it's his nickname and change it should he need to (or if he mistyped).
In essence, Pasaporte offers a page for any nickname and shows an identitifer in this
page that allows the OpenID consumer to find the server endpoint. However if this user
does not exist, never logged in or has hidden his profile that's the only thing that will
be shown - a blank page with some OpenID metadata for basic interop.
It's important to understand that a Profile record is a helper for metadata and not
something authoritative - it's the auth routine that takes the actual decision about the
user's state.
== Persistence
We store some data that the user might find useful to store and maybe display on his user
page. No sessions of the exchange are kept
except of the standard OpenID shared secrets (there are not linked to user records in any
way).
== SREG data sharing
There is currently no provision for fetching SREG data (like email, date of birth and such)
from the autorizing routine. We might consider this in the future, for now the user has to
fill it in himself.
== Sharding
The users in Pasaporte are segregated by the domain name of Pasaporte server. That is, if
you have two domains pointed at +one+ Pasaporte, you will not have name clashes between
the two domain names - the users are going to be split.
This is Pasaporte, a small identity server with a colored bar on top. It's in the style
of Crowd (but smaller). Will act as a mediator between OpenID and arbitary services where
users are distinguished by their nickname (login), their password and a domain name.
== The idea
Pasaporte brings OpenID to the traditional simplicity of
is_a_villain = check_password(login, password, domain)
The only thing you WILL need to change is the AUTH constant. It should contain the proc
that, when called, will return true or false. Yes, it's that simple. All the negotiation
smorgasbord, profile editing, encryptodecryption and other electrabombastic niceties are
going to be taken care of.
Here is an example of a simple auth procedure:
# Stick your super auth HERE. Should be a proc accepting login, pass and domain
Pasaporte::AUTH = lambda do | login, pass, domain |
allowd = => "secret"
return (allowd[login] && (allowd[login] == pass))
end
Obviously you can let your auth procedure look up in ACLs and things like that if you
really need it to.
If the password becomes stale or should the authentication backend say that it no
longer has the user in question the authorization tokens are immediately revoked, and any
authorization requests will be denied.
== Using SSL
It is recommended that you run pasaporte in full SSL mode. However,
some OpenID consumers disallow OpenID providers with self-signed (i.e. free)
SSL certificates. Pasaporte mitigates this by offering the "partial SSL" mode. When turned on,
only the signon page (where the password is entered) and subsequent pages with which the user
interacts will be protected with SSL encryption, while the public OpenID endpoint will NOT be
SSL-enabled. Same is true for the server-server step of OpenID handshake.
This will allow even stricter providers to use Pasaporte servers, but without passing the user login
over the wire in clear text.
When partial SSL is turned on, the profile page (OpenID identity) will forcibly be made
unencrypted (will redirect to non-secure port).
Partial SSL is disabled by default - to enable set PARTIAL_SSL to true.
== Current issues
As of now, we are not aware of sites that cannot consume OpenID from Pasaporte.
There is currently no provision for verifying that the URL you are logging in from is the
one Pasaporte manages.
== Configuration
The adventurous among us can override the defaults (Pasaporte constants) by placing a
hash-formatted YAML file called "config.yml" in the pasaporte dir. And don't ask me what
a "hash-formatted YAML file" is, because if you do you are not adventurous.
Here the rundown of the config parameters:
MAX_FAILED_LOGIN_ATTEMPTS - after how many login attempts the user will be trottled
THROTTLE_FOR - Trottle length in seconds
ALLOW_DELEGATION - if set to true, the user will be able to redirect his OpenID
SESSION_LIFETIME - in seconds - how long does a session remain valid
PARTIAL_SSL - see above
HTTP_PORT - if partial SSL is used, the port on which the standard version runs
SSL_PORT - if partial SSL is used, the port on which the secure version runs
== Profiles
Pasaporte allows the user to have a simple passport page, where some info can be placed
for people who follow the OpenID profile URL. Sharing the information is entirelly optional.
== The all-id
The login that you use is ultimately the nickname that comes in the URL. For that reason
no other login name can be entered in the form. However the user still can verify that
it's his nickname and change it should he need to (or if he mistyped).
In essence, Pasaporte offers a page for any nickname and shows an identitifer in this
page that allows the OpenID consumer to find the server endpoint. However if this user
does not exist, never logged in or has hidden his profile that's the only thing that will
be shown - a blank page with some OpenID metadata for basic interop.
It's important to understand that a Profile record is a helper for metadata and not
something authoritative - it's the auth routine that takes the actual decision about the
user's state.
== Persistence
We store some data that the user might find useful to store and maybe display on his user
page. No sessions of the exchange are kept
except of the standard OpenID shared secrets (there are not linked to user records in any
way).
== SREG data sharing
There is currently no provision for fetching SREG data (like email, date of birth and such)
from the autorizing routine. We might consider this in the future, for now the user has to
fill it in himself.
== Sharding
The users in Pasaporte are segregated by the domain name of Pasaporte server. That is, if
you have two domains pointed at +one+ Pasaporte, you will not have name clashes between
the two domain names - the users are going to be split.