Samsung Galaxy S3 päivitys: Android Jelly Bean 4.3

Jep, tiedän, ei ole niin kiintoisaa kun Galaxy S5:seen saa suoraan KitKat 4.4:sen, mutta aika iso päivitys tuli Samsung Galaxy S3:seenkin. Hyppy 4.1 versiosta suoraan 4.3:seen, KIES:in kautta. Tuntuu liukkaammalta ja näyttää kauniimmalta, ja kuulemma KitKat olisi putkessa vielä ensi vuonna. Ei hullumpaa..

Kuva

Kuva

Jos latauksista tulee ilmoituksia päivityksen jälkeen, etsi Downloads/Lataukset sovellukset, putsaa cachet ja data, ja sitten vain buuttia kehiin.

Parhaita uusiavuosia itsekullekin! Muistakaa kääntää puhelimet pois päältä vaikka sitten yhdeksi teemapäiväksi 😉

Mainokset

Active Directory Autentikointi, LDAP, ja Glassfish

Toteutin aikanaan Active Directory LDAP pohjaisen autentikoinnin Glassfishillä pyörivään REST palveluun ja web sovellukseen, jossa on mahdollista käyttää Windows domain tunnuksia sisäänkirjautumiseen ja palveluiden käyttöön. Alunperin tehdessä homma toimi aika suorasukaisesti, AD ryhmän voi suoraan liittää Glassfish rooliin, mutta logiin jäi harmillista toistuvaa moskaa joka ei vaikuttanut toimintaan mutta silti ihmetytti. Kyseessä oli tällainen virheilmoitus:

Caught exception. javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ’DC=mycompany,DC=fi’

Tästä samasta oireesta tuntui kärsivän puoli Internettiä, vailla ajatuksia ja vastauksia miten ratkoa tämä. Tuntui olevan jonkun asteinen verkko-infra oire.  Ohjeistus oli monesti käntää ympäristöasetus java.naming.referral asentoon ignore – tai follow. Kumpikaan ei auttanut oireeseen tässä tapauksessa.

Viime viikolla löysin viimein korjauksen joka toimi, eli ongelman sai poistumaan yksinkertaisesti vaihtamalla porttia jota käytetään AD:n kanssa keskusteluun, vanhsta portista 389, jota useimmat ohjeet suosivat, uuteen porttiin 3268 (Global Catalog) – josta voi tehdä hakuja seuraamatta automaattisesti kaikki linkkejä. Tässä siis toimiva esimerkki Glassfish 4 AD autentikoinnista:

<auth-realm name="TieturiActiveDirectory" classname="com.sun.enterprise.security.auth.realm.ldap.LDAPRealm">
    <property name="directory" value="ldap://ournameservername:3268"></property>
    <property name="base-dn" value="DC=mycompany,DC=fi"></property>
    <property name="jaas-context" value="ldapRealm"></property>
    <property name="assign-groups" value="mygroup"></property>
    <property name="search-filter" value="(&amp;(objectCategory=user)(sAMAccountName=%s))"></property>
    <property name="search-bind-dn" value="mylogin"></property>
    <property name="search-bind-password" value="mypassword"></property>
    <property name="group-search-filter" value="(&amp;(objectCategory=group)(member=%d))"></property>
</auth-realm>

Tärkeä avain tuossa yllä on myös assign-groups arvo, se määrittää mihin Glassfish ryhmään autentikoidut käyttäjät tuitataan. Ryhmän voi taas mäpätä haluamaansa rooliin. Parametreja säätämällä lisää voi tarkentaa lisää hakuehtoja joilla suodatetaan hyväksyttyjä tunnuksia tiukemmin.

Kannattaa käyttää tuossa filtterissä objectCategory-parametria objectGroup:in sijaan, koska objectCategory on indeksoitu ja nopeampi. Oikeasti kannattaa myös suodattaa disabled-tilassa olevat tunnukset pois, esim. näin:

<property name="search-filter" value="(&amp;(objectCategory=user)(sAMAccountName=%s)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"></property>

Tarina perustuu tositapahtumiin. Luonnollisesti kaikki nimet ja ip-osoitteet ovat muutettuja ja yksinkertaistettuja jotta asianomaisia suojellaan riittävästi.

Tiivistettä Javalla

Kauan aikaa sitten kouluttelimme kurssia Java Security. Jostain syystä se ei ollut koskaan suuri hitti, niihin aikoihin tietoturva kuten testauskin oli harvojen herkkua, koska molemmat tehtiin projektien lopussa vähäisellä prioriteetilla, pienikin viivästys aiheutti sen että karsitaan tietoturvasta ja testauksesta. Ja siksi harvoja kiinnosti miten Java-kielessä voi kryptata sisältöä raskaillakin algoritmeilla tai miten dataan voi tehokkaimmin laskea tiivisteitä tai enkoodata tai dekoodata sitä esim. base64 muotoon.

Rajapinnat olivat kuitenkin suorastaan hauskoja ja helppoja, joten on vähän sääli että niitä ei ole päässyt sen enempiä käyttelemään itsekään. Pitkästä aikaa törmäsin artikkeliin jossa käsiteltiin näitä, ja ajattelin verrytellä koodiesimerkin toimivaan kuntoon. Nykyään tietoturva alkaa taas pakostakin olemaan enemmän tapetilla, ja luottamuksellisuus ja kiistämättömyys voivat olla taas tavoiteltavia asioita.

Eli tässä koodipätkä itselleni muistiin, miten Java-kielen valmiilla piirteillä voi laskea datasta sha-1 -tiivisteen, ja samaan syssyyn Base64-koodata sen siirtoa tai talletusta varten:

public class MessageDigestTest {
    public static void main(String[] args) throws NoSuchAlgorithmException, UnsupportedEncodingException {
        String sourceString = "HelloWorldTextToDigest";
        System.out.println("Source text:" + sourceString);
        String returnString = "";
        MessageDigest messageDigester = MessageDigest.getInstance("SHA-1");
        messageDigester.update(sourceString.getBytes("utf8"));
        returnString = new String(Base64.encode(messageDigester.digest()));
        System.out.println("Base64 encoded SHA-1 digest of source string:" + returnString);
    }
}

Pari huomioitavaa asiaa koodiesimerkistä:

  • Base64 on nykyisellään Javassa ei-standardi HotSpot myllyn sisäinen toteutusluokka, niinkin mehukkaassa paketissa kuin com.sun.org.apache.xerces.internal.impl.dv.util.Base64 – eli sen läsnäoloon tai rajapinnan muuttumattomuuteen ei voi luottaa
  • Java 8 tuonee mukanaan tästä standardipaketti-version, jossa rajapinta pysyy samana ja joka näin ollen löytyisi kaikista virtuaalikoneista aikanaan, Base64 muuttuu siis helpommaksi. Java 8:ssa Base64-luokka löytyy paketista java.util. Aiemmille toteutuksille voi olla hyvä käyttää jotain 3rd party kirjastoa jota voi itse hallita
  • MessageDigest taas on sisäänrakennettu hyvinkin vanha luokka. Sen kautta voi käyttää mitä hyvänsä Javalle saatavilla olevia alghoritmeja, nykyisiä ja tulevia, tiivisteen laskemiseen. Algoritmeja löytyy esim. SHA-1, SHA-256, SHA-384, SHA-512, MD2 ja MD5.
  • Samaan tapaan Java-kielessä toimii myös luokka nimeltä Cipher, jolla voi kryptata sisältöä. Sekin luodaan ensin, sitten update toiminnolla dataa sisään, ja lopuksi kryptattu versio ulos. Tähän tulee mukaan myöa avaintenhallinnan rajapinnat. Nykyisellään Cipher tukee algoritmeja kuten AES,AESWrap,ARCFOUR, DES,DESede, RSA, mutta myös esim. Blowfish, ECIES (Elliptic Curve Integrated Encryption Scheme), ja lukuisia muita. Jos ne eivät riitä, lisäalgoritmeja pystyy asentamaan. Noista mainituistahan saa nykypäivänä unohtaa heti osan algoritmeista, koska niitä ei pidetä enää turvallisena.
  • Pienenä haasteena jenkkilässä rinnastetaan kryptografiaa aseisiin ja ammuksiin, ja järeiden avainvahvuuksien algoritmeilla on rajoituksia maastaviennin suhteen. Tämän vuoksi oletus-Java asennuksessa avainten maksimivahvuus on rajoitettu ja avatakseen täyden vahvuuden avaimet täytyy asentaa virtuaalikoneeseen lisäpalikkaa. Tai kirjoittaa pieni koodihäkkäys joka poistaa eston.
  • Lisätietoa algoritmeista esim. http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest