view release on metacpan or  search on metacpan

zxid-faq.pd  view on Meta::CPAN

3.  Entity ID SHOULD be the Well Known Location (WKL), i.e. the
    URL from which the metadata can be fetched.

4.  Providing metadata by URL, ideally by the Entity ID, SHOULD
    always be enabled. This greatly facilitates configuration.

5.  <KeyDescriptor> elements should have ~use~ XML attribute

6.  After you get an installation to work, be sure to review whether
    the default configuration is appropriate for production use

    a. Decide whether you want to run open federation, see MD_FETCH
       config option (default: 1=open federation)
    b. Prune your Circle of Trust. Use zxcot(8) tool to list who you
       trust and delete the misfits.
    c. Check validity time tolerances you accept: BEFORE_SLOP
       and AFTER_SLOP. The defaults are rather generous for
       production use.
    d. Review that you did not turn off any signature
       validation just to get it to work (SIG_FATAL=0, NOSIG_FATAL=0
       and similar config options). All signature
       validations are there for reason and you should not
       go to production if any of them fail.
    e. Check permissions on /var/zxid/pem and think whether
       your private keys, including web server SSL one,
       are protected. Could they have been compromised
       during trial period?
    f. Check that your public image is conveyed right in your metadata,
       e.g. NICE_NAME, ORG_NAME, ORG_URL, and FEDUSERNAME_SUFFIX (if
       used, generally only on IdP). However, be forewarned
       that changing these on last minute changes your metadata and you may
       need to engage in an additional round of metadata exchanges
       when you go to production.
    g. Make sure you have a solution in place to keep your audit trail
       in case you ever have to go to court. See zxid-log.pd for
       details. You may also want to think about encrypting or deleting some
       items after a while to reduce your liability for breaches.

97.15 Cardspace / Infocard / DigitalMe Tutorial
-----------------------------------------------

N.B. zxid.org does not yet support Infocard, but since we
are starting the investigation, we thought to share
some of it in next sections...

97.15.1 Installing DigitalMe and Firefox plugin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DigitalMe by Bandit project is an open source Infocard
implementation, providing functionality roughly similar to
CardSpace. You can download it from

  http://www.bandit-project.org/index.php/Digital_Me

rpm2cpio digitalme-0.4.1238-2.1.i586.rpm | cpio -di

97.15.2 Setting up IdP account
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For one InfoCard aware IdP, please see: http://www.cdatazone.org/index.php?/archives/27-Managed-Infocard-Demo.html

1. Register at the IdP site (e.g. https://www.ctindustries.net/icard/index.php)
2. Download the card ("Retrieve Managed Card" link (savea as "cdatamanaged.crd" by default).
3. Install the card to DigitalMe

97.15.3 Yubikey Support
~~~~~~~~~~~~~~~~~~~~~~~

ZXID supports the yubikey USB One Time Password (OTP) tokens from yubico.com.
The token should be personalized such that the prefix of the ticket is the
UID and the remainder is the ticket proper. The AES128 shared secret in hex is
populated in UID/.yk directory. See also zxid-log.pd for description.

You would typically plan the user names, taking in account the yubikey modhex 
restrictions, and then use ykpersonalize to create thephysical tokens. At the
same time you would generate and record the AES128 shared secrets to the .yk
files (and inside the yubikey USB tokens themselves, of course).

The contents of the .yk file is 32 hexadecimal digits (ascii 0-9a-f)
representing 128 bits of key information.

The value is not hashed, salted, or nonced, so it needs to be carefully
protected by the filesystem permissions.

97.16.9 Legal
~~~~~~~~~~~~~

Microsoft promises to not sue you: http://www.microsoft.com/interop/osp/default.mspx

97.17 Attributes
----------------

Q:: I want to read the attributes that come in the assertion. How do I do that?

A:: You get attributes back as an LDIF entry as return value of zxid_simple()
    The attributes are also available by reparsing the assertion, which gets
    stored in /var/zxid/rely hierarchy.

    /var/zxid/ses/SuzZQS5Ub/.ses file contains the path to the assertion file.

Q:: In the zxid directory you store some users. What does the extension .mni stand for?
    Why is the info stored? I assume it is some sort of local cache. I would like
    to store the attributes there too. How do I do that?

A:: The .mni file is used to support Manage NameID requests. In normal operation of ZXID
    it really is not needed, but to support some of the SAML conformance test requests
    it is needed.

    Rather than store attributes in that directory, I'd suggest reparsing
    the assertion when you need them. But if you must, you could create a
    file of your own in that directory. We of course need a naming
    convention that prevents naming conflicts with future versions of
    ZXID: Your file extension should start by ".x-", for example:
    "attributes.x-attr"

Q:: The ldif returned by zxid_simple() is perfect for my needs, but
    nothing is being stored in log/rely directory. Could be some
    configuration issue? Also, can I have zxid automatically store the
    ldif file returned zxid_simple()?

A:: The log/rely should be populated by default, but if the directory
    structure itself is missing, may be it does not work. Try make dirs.
    Or check that web server user's permissions allow writing there.